TOS Silver 2000/TOS Silver 2000.iso/programm/Mm2_txt/MODULA2F.TXT

Text File | 1997-02-07 | 174.3 KB | 3,421 lines

2.1  Bedienung: Los geht's                                                2 -  1
________________________________________________________


2.      Bedienung  des  Systems


Wir haben uns bemüht, die Verwendung von Fremdwörtern zu vermeiden oder
diese  mit  Übersetzungen  zu  versehen.  Aber  gerade  im  Computerjargon
kommen viele aus dem Englischen übernomme Ausdrücke vor, die kaum direkt
übersetzbar sind oder Einsteigern gar nicht bekannt sein können. Stoßen Sie in
diesem Handbuch auf solche Ausdrücke, sehen Sie doch einfach nach, ob wir
dazu eine Begriffserläuterung im Anhang dieses Buchs  nachgetragen  haben.
Wir haben uns bemüht, diese Ausdrücke kursiv hervorzuheben.


2.1    Los  geht's  -
          Installieren  und  Ausprobieren


Voraussetzungen

Wir gehen davon aus, daß Sie vor Ihrem Atari ST-Computer sitzen und neben
diesem  Handbuch  die  mitgelieferten  Disketten  zur  Hand  haben.  (Die  Regi~
strierkarte, die der Lieferung beilag, haben Sie bestimmt schon ausgefüllt, um
in den Genuß aller Updates und Erweiterungen zu Megamax Modula zu kom~
men?)

Außerdem sollten Sie einige leere Disketten bereithalten, um Backup- (Sicher~
heits-) und Arbeitskopien anzulegen: 4 doppelseitige Disketten  für  Backups;
zusätzlich 2 Disketten für die Zusammenstellung maßgeschneiderter Arbeits~
disketten. (Natürlich genügt auch etwas Platz auf einer Festplatte...)

Einige Worte zur Konfiguration des Rechners: Für ein komfortables Arbeiten
mit Megamax Modula ist eine freie RAM-Kapazität von  2  MByte  und  einer
Festplatte wünschenswert.

Die Benutzung von Megamax Modula auf einem Atari mit nur 512 KByte RAM
ist nicht möglich. Voraussetzung dafür wäre eine gegenüber der mitgelieferten
stark verkleinerte Shell, die kein GEM benutzt.  Eine  solche  Shell  ist  zwar
schnell erstellt, aber wir weisen lieber darauf hin, den Atari auf mindestens
1 MByte aufzurüsten. In den Fachzeitschriften lassen sich einfach einzubauende
Speichererweiterungen schon für ca. DM 300.- finden.
2.1  Bedienung: Los geht's                                                2 -  2
________________________________________________________


Die Modula-Disketten

Die Aufteilung und Anzahl der mitgelieferten Disketten variiert von Zeit zu Zeit,
so daß wir Ihnen hier nur alle zumindest vorhandenen Dateien und Ordner auf~
zeigen, um Ihnen die Übersicht zu erleichtern. In der Regel werden die Disket~
ten zweiseitig beschrieben - wenn Sie sie nicht in den Computer einlesen kön~
nen, wenden Sie sich bitte an Ihren Händler, damit er Ihnen die Disketten auf
einseitige umkopiert, oder an Application Systems. Über weitere Besonderheiten
und zusätzliche Dateien werden Sie in der Datei LIESMICH.TXT informiert, die
sich auf einer der Disketten befindet.

    GEP ED           Ordner, der den Gepard-Editor enthält:
         _
       GEP ED.MOD     Der Gepard-Editor (nur unter der Shell zu starten!)
           _

    GME               Ordner; enthält die Dateien für den Editor "GME"
       GME.MOD         Der Editor
       ...IMP              Zum GME gehörende Module
       GMEMENUE.RSC  Die GEM-Resource-Datei für den GME

    SRC               Ordner mit Quelltexten. Enthält vier Ordner für:
       D                  Definitions-Texte. Achtung: Sind ggf. erst zu dekom-
                           primieren (siehe HINWEIS-Text auf der Diskette)
       DEMO             Diverse Demonstrationsprogramme
       MOS              Quellen zum Megamax-System, die Sie bei Bedarf
                           selbst modifizieren können (z.B. die Shell)
       UTILITY           Diverse Hilfsprogramme

    SYS               Ordner mit Modulen und anderen Systemdateien:
       IMP                Ordner mit den übersetzten Implementations-Modulen
                           (werden beim Ausführen vieler Programme unter der
                           Shell benötigt)
       MOD              Ordner mit Compiler, Linker, Make usw.
       DEF               Ordner mit übersetzten Definitions-Modulen (werden
                           vom Compiler beim Übersetzen benötigt):
         MM2DEF.M2L     Enthält die unveränderlichen DEF-Module der Mega-
                             max-Bibliothek in komprimierter Form.
         MM2SHELL.DEF   Ein einzelnes DEF-Modul: Es definiert die Resource-
                             Indices der Shell und kann sich ändern, wenn die
                             GEM-Resource modifiziert wird.
       MODULA.ERR      Textdatei mit Fehlermeldungen für den Compiler

    USER              Ordner für Ihre eigenen (Quelltext-) Dateien.
       DEF               Hier kommen übersetze Definitions-Module rein
       IMP                Dito für Implementations-Module
       MOD              Dito für Haupt-Module
                        Die Quelltexte sollten auch hier im Ordner USER abgelegt
                        werden.
2.1  Bedienung: Los geht's                                                2 -  3
________________________________________________________


    TMP               Ordner, in dem die Shell interne Dateien zwischenzeitlich
                        ablegt (auch das Make-Programm!).

    TEMPLMON.Vxx   Ordner mit Maschinensprache-Monitor.

    MM2SHELL.PRG   Die Modula-Shell (Bedienungsoberfläche)
    MM2SHELL.RSC   GEM-Resource-Datei für die Shell
    MM2SHELL.RSD   Zusatzdatei zur Resource-Datei
    MM2SHELL.M2P   Parameter-Datei für die Shell
    MM2SHELL.M2B   Batch-Datei - wird beim Shell-Start ausgeführt
    MM2SHELL.HLP   Textdatei mit Hilfestellungen für die Shell-Bedienung

    LIESMICH.TXT     Diese Datei unbedingt lesen! (z.B. nach dem Shell-Start
                        durch einen Doppelklick in den Editor laden)

    NRSC ASH.PRG   Programm zum Bearbeiten von GEM-Resourcen
          _
    NRSC.RSC         Resource-Datei zum Programm
           Das  "Resource  Construction"-Programm  wird  zur  Erstellung  von
           GEM-Menues und anderen GEM-Objekten benötigt. Mehr dazu finden
           Sie in den Kapiteln 5 und C.2.

    HD INST.PRG     Hiermit  kann  das  Modula-System  bequem  auf  der
       _
                        Festplatte installiert werden.

    DEMO enthält einige Beispielprogramme, die Ihnen vielleicht den Einstieg in
    Megamax Modula erleichtern. In UTILITY finden sich einige Hilfsprogramme,
    die Sie compilieren sollten, um dann die erzeugten Code-Dateien auf ihre
    Arbeitsdisk (Ordner SYSüMOD) zu kopieren. Sehen Sie sich  alle  diese
    Dateien an, z.B., indem Sie sie in den Editor laden. Sie enthalten alle eine
    Information zu Beginn des Textes.

    Der Ordner MOS ist eher für fortgeschrittene Benutzer interessant: Er
    enthält die Quelltexte einiger Module, die Sie verändern können, um die
    Konfiguration der Bibliotheken und der Entwicklungsumgebung (Shell) Ihren
    eigenen Wünschen anzupassen.

    Besonders hilfreich ist der Ordner D. Er enthält die Definitionstexte, die
    auch  im  Kapitel  B  dieses  Handbuchs  abgedruckt  sind.  Aus  Erfahrung
    wissen wir, daß man oft Funktionen nachschlagen will und es dann beim
    üblichen Schreibtischchaos recht  unbequem  ist,  im  Handbuch  herumzu~
    blättern. Wenn Sie genügend Massenspeicher (Festplatte) haben, reicht es
    nun  aus,  im  Editor  ein  neues  Fenster  zu  öffnen  und  den  benötigten
    Definitionstext hineinzuladen. Der  Gepard-Editor  erlaubt  es  sogar,  nach
    exportierten Bezeichnern zu suchen und dann die entsprechende Definitions-
    Textdatei  anzuzeigen  (mit  der  F6-Taste,  wenn  der  Cursor  auf  dem
    gesuchten Bezeichner steht!).
2.1  Bedienung: Los geht's                                                2 -  4
________________________________________________________


Installieren von Megamax Modula

Auf die Gefahr hin, daß wir Sie langweilen: Haben Sie schon Backup-Kopien
aller gelieferten Disketten gemacht? Die Disketten sind nicht kopiergeschützt.
Es  sollte  also  keine  Schwierigkeiten  bereiten,  Kopien  anzufertigen  und  die
Originale in Sicherheit zu bringen. Vorsicht: Vor dem Kopieren sollten Sie die
Originale schreibschützen (Loch ist offen), um sie bei einer Verwechslung nicht
gleich zu löschen!

Mit den Kopien in der Hand können Sie sich jetzt Ihre Arbeitsdisketten zusam~
menstellen. Wir beschreiben zwei verschiedene Rechner-Konfigurationen:
* Atari ST mit mindestens 1 MByte RAM, mindestens 720 KByte Diskettenplatz
* Atari ST mit mindestens 1 MByte RAM, Festplatte


Atari ST mit mindestens 1 MByte RAM, mindestens 720 KByte Diskettenplatz

Die gelieferten Disketten sind bereits sinnvoll aufgeteilt. Auf der Disk mit der
Shell   befinden   sich   neben   den   für   die   Shell   notwendigen   Dateien
(MM2SHELL.M2P,  MM2SHELL.M2B,  MM2SHELL.RSC)  auch  die  Module,  die
resident  geladen  werden:  der  Compiler  (im  SYSüMOD-Ordner)  und  beide
Editoren (Ordner GEP ED bzw. GME). Die andere Diskette enthält dann die
                       _
zum Arbeiten benötigten Dateien, wie  Definitions-Codes  (MM2DEF.M2L)  und
importierte Module (Ordner SYSüIMP). Ihre selbst übersetzten Dateien werden
im USER-Ordner abgelegt, worin Sie auch Ihre Quelltexte ablegen können.

Sie können also die Shell von der einen Diskette starten; ist sie fertig, kann
die  andere  Disk  eingelegt  werden,  um  dann  eigene  Programme  oder  die
mitgelieferten Programme in den Ordnern DEMO und UTILITY zu übersetzen
und zu starten.

Beachten  Sie  aber,  daß  die  Parameter-Datei  der  Shell  auf  der  Boot-Disk
abgelegt ist. Wenn Sie den Menüpunkt Parameter ...speichern wählen oder die
Parameter beim Verlassen der Shell speichern wollen, müssen Sie zuvor die
Boot-Disk einlegen. Es passiert zwar nichts schlimmes, wenn Sie dies nicht
befolgen, allerdings würde beim erneuten Start der Shell von der Boot-Disk
wieder die alte Parameter-Datei geladen werden. Notfalls können Sie die Datei
auch einfach auf die Boot-Disk zurückkopieren.

Ein ähnliches Disketten-Problem entsteht bei der  Benutzung  des  GME.  Der
Editor benötigt beim Start seine Resource-Datei GMEMENUE.RSC. Wenn Sie
nur ein Laufwerk haben, müssen Sie aufpassen, daß beim Start des Editors
eine Disk mit dieser Datei im Ordner  GME  einliegt.  Wollen  Sie  Texte  von
anderen Disketten vom Laufwerk A: lesen, müssen Sie erst den Editor starten
(Tastendrücke:  Control-P,  Esc,  Return,  Control-E)  und  erst  dann  die  Disk
wechseln und im Editor die gewünschte Datei laden.
2.1  Bedienung: Los geht's                                                2 -  5
________________________________________________________


Besser ist es dann schon, zwei Laufwerke zu verwenden - dann braucht auch
die Boot-Disk mit der Shell und ihrer Parameter-Datei nicht entfernt werden,
so daß das vorher beschriebene Problem ebenfalls nicht entsteht. Allerdings
müssen dazu erst einige Parameter in der Shell und die Suchpfade geändert
werden.

Müssen aus Platzmangel mal  die  geladenen  Programme  (z.B.  Compiler  und
Editor) entfernt werden, werden sie bei erneuter Benutzung auf der gerade
eingelegten Diskette gesucht. Ggf. müssen Sie sich Editor und Compiler dazu
auf die Arbeitsdisk kopieren, damit Sie nicht jedesmal extra die Disk mit der
Shell wieder einlegen müssen.

Das Programm HD INST.PRG auf einer der Disketten wird beim Arbeiten nicht
                   _
benötigt und kann daher von dort entfernt werden, um Platz auf der Disk zu
gewinnen.

Um das Modula-System nach Ihren Wünschen zu konfigurieren, lesen Sie bitte
über die Parameter von Shell, Editor  und  Compiler  sowie  über  die  Batch-
Dateien für die Suchpfad-Bestimmung in Kapitel 2.2 nach.

Im  Ordner  MAXIDISK.4MB  finden  Sie  eine  RAM-Disk,  die  sogar  die  darin
gespeicherten Daten komprimieren kann. Sobald Sie mit der  Bedienung  und
Konfiguration  vertraut  sind,  können  Sie  sich  eine  Boot-Disk  erstellen,  die
automatisch die RAM-Disk einrichtet und die von Ihnen benötigten Definitions~
module sowie die Fehlerdatei MODULA.ERR in die RAM-Disk kopiert. Wenn Sie
dann  die  Suchpfade  entsprechend  einstellen,  können  Sie  das  Übersetzen
erheblich beschleunigen.


Atari ST mit mindestens 1 MByte Speicher und Festplatte

Hier ist alles ganz einfach. Sie brauchen lediglich auf der Festplatte irgendwo
einen Ordner für das  Modula-System  anzulegen  ("MM2"  wäre  ein  schöner
Name) und dann alle Dateien, so wie sie auf den Disketten angeordnet sind,
                                                          1
hineinzukopieren. Auf der Festplatte sollten dazu ca. 3 /  MB frei sein. Damit
                                                            2
es  auch  dabei  keine  Schwierigkeiten  gibt,  haben  wir  das  Programm
HD INST.PRG  vorbereitet.  Es  braucht  nur  gestartet  zu  werden  und  dann
   _
sollten Sie, wie vom Programm aufgefordert, die vier Disketten nacheinander
einlegen. Dann werden einfach alle Dateien auf die Festplatte kopiert. Weitere
Konfigurationen  brauchen  erstmal  nicht  vorgenommen  werden.  Sie  sollten
später aber noch die Definitions-Module in der Library decomprimieren. Lesen
Sie dazu Kapitel 2.4.

Schon ist alles vorbereitet - die Shell kann nun gestartet werden. Erst, wenn
Sie die Strukturen der Ordner ändern wollen, müssen Sie die Parameter in
der Shell und die Suchpfade im Batch (MM2SHELL.M2B) anpassen. Doch dazu
sollten Sie erstmal Kapitel 2.2 durchlesen!
2.1  Bedienung: Los geht's                                                2 -  6
________________________________________________________


Speicherplatzmangel?!

Wenn  Sie  nun  die  Shell  starten,  sollten  nach  dem  Laden  von  Compiler
und  Editor  mindestens  noch  200  KB  (ca.  200.000  Byte)  Speicher  frei
sein,  sonst  werden  sich  bald  Compiler,  Editor  oder  Linker  diesbezüglich
beschweren.  Vor  allem,  wenn  Sie  ein  Fan  von  Accessories  oder  AUTO-
Ordner-Programmen sind und Ihr Rechner nur über 1 MB Speicher verfügt,
kann es dazu kommen. Den noch freien Speicher können Sie über den Menü~
punkt Info/Umgebungsinformationen erfahren.

Sie haben bei zu knappem Speicher keine Datenverluste zu befürchten! Reicht
der Speicher im Editor nicht mehr, kann immer noch der bisher erzeugte Text
gesichert werden, bei Compiler, Linker und anderen Dienstprogrammen kann
die  Operation  ja  sowieso  wiederholt  werden.  Um  den  freien  Speicher  zu
vergrößern, haben Sie verschiedene Möglichkeiten:

* Geben Sie die sonst noch geladenen Programme aus dem Speicher frei (das
  zu startende Programm selbst braucht nicht entfernt werden). Dazu öffnen
  Sie das Resident-Fenster (Taste R) und ziehen die angezeigten Programme
  in den Abfalleimer. Dauerhaft können Sie auf das  Laden  der  Programme
  ganz  verzichten,  indem  Sie  die  Load-Anweisungen  aus  dem  Shell-Batch
  entfernen (siehe Kapitel 2.2).

* Verwenden Sie den Gepard-Editor. Er benötigt und belegt (als residentes
  Programm)  deutlich  weniger  Speicher  als  der  GME.  Ersetzen  Sie  dann
  die  Anweisung  LOAD  GME  durch  LOAD  GEP ED  in  der  Batch-Datei
                                                      _
  MM2SHELL.M2B. Diese Änderung kann mit dem Editor durchgeführt werden.

* Verzichten  Sie  auf  andere  residente  Programme,  wie  Accessories  oder
  AUTO-Ordner-Programme (z.B. Cache).

* Starten Sie den Compiler bzw. den Linker als gelinktes Programm von einer
  anderen Shell aus. Diese Lösung ist zwar nicht so komfortabel wie mit der
  Megamax-Shell, aber löst dafür auch die größten Platzprobleme. Siehe dazu
  die Erläuterungen in den Quelltexten von LinkInit und CompInit (LINKINIT.M &
  COMPINIT.M im UTILITY-Ordner).
2.1  Bedienung: Los geht's                                                2 -  7
________________________________________________________


Mehr Geschwindigkeit...

Haben Sie keine Platzprobleme, können Sie Ihr System auf Geschwindigkeit
trimmen. Hier einige Tips:

Wenn Sie eine Festplatte haben, verwenden Sie unbedingt TOS 1.4 (Rainbow-
TOS, enthält u.A. die Zahl 1989 in der Info-Box des Desktops) oder höher. Die
älteren TOS-Versionen sind sehr, sehr langsam beim Speichern und Laden.
Das TOS 1.4 gibt es bei fast jedem Atari-Händler; oder sehen Sie mal in die
Kleinanzeigen der Computerzeitschriften.

Haben Sie TOS 1.4 (oder höher), verwenden Sie das Cache-Programm von
Atari! Es heißt beispielsweise CACHE90.PRG und gehört in den AUTO-Ordner.
Gegenüber den meisten  anderen  Caches  puffert  dieser  nicht  wahllos  jeden
Sektor,  sondern  gezielt  FAT  und  Verzeichnisse.  Da  Megamax  Modula-2
intensiver als jedes andere Programm auf die Verzeichnisse zugreift, macht
sich der Atari-Cache hier besonders gut bemerkbar. Zudem: Da es im Grunde
kein Disk-Treiber ist, sondern lediglich die Puffer des GEMDOS erweitert, ist
es prinzipbedingt jedem anderen Cache überlegen.

Wie gesagt, Megamax Modula-2 greift häufig auf die Dateiverzeichnisse zu, um
Modulcodes  und  -definitionen  zu  laden.  Deshalb  sollten  die  am  häufigsten
benötigten Dateien möglichst schnell gefunden werden. Dazu sollten  Sie  die
Suchpfade entsprechend ordnen: Am Besten wäre es, wenn sich alle Dateien
im jeweils ersten Suchpfad befänden.

Sie sollten die  Definitionsdateien  in  der  Bibliothek  MM2DEF.M2L  entpacken.
Mehr dazu im Kapitel 2.4.

Überhaupt  genießt  die  Bibliotheksdatei  einen  Sonderstatus:  Beim  Start  des
Compilers  wird  sie  einmal  geöffnet,  das  gesamte  Verzeichnis  wird  in  den
Speicher  geladen.  Die  darin  befindlichen  Dateien  werden  am  Schnellsten
gefunden.  Sie  können  Ihre  eigenen  Definitionsmodule  auch  in  diese  Datei
einfügen (mit dem LibManager, s. Kap. 2.4).

Benutzen  Sie  Turbo  ST  oder  Quick  ST.  Dies  sind  Programme,  die  die
GEM-Bildschirmausgaben um ein Vielfaches beschleunigen. Wir empfehlen Ihnen
Quick  ST,  das  auch  Erweiterungen  wie  Hyperscreen/Overscan  und  GDOS
unterstützt. Sie erhalten Quick ST gegen Einsendung eines Schecks über 25
US Dollar bei folgender Adresse:

        Branch Always Software
        14150 N.E. 20th St. #302
        Bellevue
        WA 98007
        USA
2.1  Bedienung: Los geht's                                                2 -  8
________________________________________________________


Namenskonventionen

Falls Sie schon mit anderen Modula-2-Systemen gearbeitet haben, wollen wir
Sie gleich darauf hinweisen, daß wir  andere  Endungen  bei  den  Dateinamen
verwenden. Die Quelltexte haben alle nur einen Buchstaben als Endung, und
zwar M für Haupt-, I für Implementations- und D für Definitionsmodule. Die
entsprechenden Code-Dateien haben  MOD,  IMP  bzw.  DEF  als  Endung.  Der
Name der Code-Datei wird nicht aus dem der Quelldatei gebildet, sondern aus
den ersten acht Buchstaben des Modulnamens, der im Quelltext steht.

Wenn Sie gerne andere Endungen verwenden wollen, brauchen Sie lediglich die
Variablen im Quelltext der Shell (MM2SHELL.M) zu ändern (suchen Sie dort
nach den z.Zt. verwendeten Endungen), übersetzen und die Shell neu zu linken
(siehe dazu Kapitel 2.6). Natürlich müssen Sie auch noch die Endungen der
mitgelieferten Dateien alle ändern, auch die in der Library (MM2DEF.M2L).


Mathe-Koprozessor (FPU, SFP004, Atari TT)

Während der Atari TT serienmäßig über eine FPU verfügt, können Sie sie beim
Atari ST/STE nachrüsten (z.B. SFP004 von Atari). Beim ST wird in der Regel
ein 68881, beim TT ein 68882 eingesetzt. Beide sind weitgehend identisch, so
daß wir beim Prozessortyp keine Unterschiede machen brauchen.

Allerdings wird eine FPU im ST anders angesteuert als im TT. Aus Gründen,
die im Kapitel über den Compiler (Kap. 3.4,  F-Direktive)  weiter  ausgeführt
werden, müssen Sie die Shell bzw. alle gelinkten Programme mit den dafür
angepaßten FPU-Modulen binden, um die FPU auch nutzen zu können. Dazu
verwenden Sie je nach Rechnertyp die Module aus den Ordnern ST FPU bzw.
                                                                       _
TT FPU.
   _

Das einfachste ist, die Module aus einem der Ordner in den IMP-Ordner zu
kopieren.  Dabei  werden  allerdings  die  "normalen"  Module,  die  keine  FPU
benutzen, überschrieben. Wenn Sie schon mit  der  Änderung  der  Pfadlisten
vertraut sind, tragen Sie besser den passenden FPU-Ordner als jeweils ersten
Suchpfad bei DefaultPath und ImpPath ein. Dann werden die Dateien dieses
Ordners bevorzugt verwendet.

Linken  Sie  dann  die  Shell  neu,  damit  Programmodule,  die  unter  der  Shell
übersetzt und per Loadtime-Linking  gestartet  werden,  auch  gleich  die  FPU
mitbenutzen können. Wie Sie die Shell linken, erfahren Sie in Kapitel 2.6; oder
starten Sie einfach den Batch LINKSHEL.M2B.

Mit den FPU-Modulen gelinkte Programme können Sie nicht auf Rechnern ohne
die entsprechende Hardware einsetzen! Sie werden dann eine Fehlermeldung
erhalten.
2.1  Bedienung: Los geht's                                                2 -  9
________________________________________________________


Ein erstes Programm

Um Megamax Modula richtig nutzen zu können, sollten Sie als nächstes die
Kapitel 2.2 (Shell), 2.3 (Editor) und 2.4 (Compiler) lesen. Bevor Sie größere
Programme schreiben, verdient auch Kapitel 3 Ihre Aufmerksamkeit. Aber viel~
leicht sind Sie im  Moment  einfach  neugierig,  ob  Ihr  neues  Modula-System
überhaupt funktioniert? Dann tun Sie doch erstmal folgendes...

Shell starten

Bereiten  Sie  den  Atari  vor,  wie
oben für Ihre Rechner-Konfiguration
beschrieben, und legen Sie ggf. die
Diskette  mit   MM2SHELL.PRG   in
Laufwerk   A   ein.   Starten   Sie
MM2SHELL.PRG     durch     einen
Doppelklick.  Nach  einiger  Zeit  er~
scheint eine Arbeitsfläche, die dem
GEM-Desktop ähnelt:

Programm eingeben

Auf der Arbeitsfläche finden Sie unter anderem eine Box Aktuelle Datei. Im
Namensfeld sollte hinter TEXT kein Name stehen. Um dies ggf. zu erreichen,
können  Sie  das  Feld  doppelt  anklicken  oder  Control-P  drücken.  Daraufhin
können Sie dann einen Text eingeben - drücken Sie Esc und dann Return als
Bestätigung. Dann ist das Feld der Aktuellen Datei leer.

Nun soll der Editor gestartet werden. Dazu halten Sie entweder
die  rechte  Maustaste  gedrückt,  während  mit  der  linken  das
Editieren-Symbol  doppelt  angelickt  wird,  oder  Sie  drücken
Control-E. Damit wird die - leere - aktuelle Datei bearbeitet.

Geben Sie nun das folgende Programm im Editor ein - bitte mit korrekter
Groß- und Kleinschreibung!
2.1  Bedienung: Los geht's                                                2 - 10
________________________________________________________



Programm sichern

Wenn     das     komplette
Programm   eingegeben   ist,
fahren Sie mit der Maus den
Menüpunkt  Datei  an,  und
wählen  Sie  den  Unterpunkt
Sichern  oder  Sichern  als.
Damit  wird  die  Datei  im
Speicher wieder zurück auf
Disk geschrieben.


                                             Da  dem  Editor  aber  bisher  noch
                                             kein  Name  für  die  Datei  bekannt
                                             war,  fragt  er  zuerst  danach.  Es
                                             erscheint  der  GEM-Datei-Selektor,
                                             in  dem  nun  ein  Name  für  den
                                             Programmtext     anzugeben     ist.
                                             Nehmen   wir   ERSTESPR.M   und
                                             speichern es im Ordner USER.






Nun kann der Editor verlassen werden. Dazu ist
entweder Alternate-X zu drücken oder im Menü
Beenden anzuwählen.




Programm übersetzen

Damit  von  nun  an  in  der  Shell
das Ansprechen der Datei einfacher
wird,  machen  wir  das  Modul  zur
Arbeitsdatei, indem N gedrückt oder
der  entsprechende  Menüpunkt  in
der Shell angewählt wird.

Nun ist ein kleines Feld auf dem Desktop der Shell erschienen. Darin soll der
Name der Textdatei eingetragen werden. Dies kann manuell durch die Taste P
oder durch einen Doppelklick auf das Feld vorgenommen werden.
2.1  Bedienung: Los geht's                                                2 - 11
________________________________________________________


Bequemer ist es allerdings erstmal,
wenn  Sie  das  Verzeichnis  vom
Laufwerk  mit  der  Datei   öffnen
(Doppelklick  auf  das  Disk-Symbol)
und  dann  die  Datei,  wie   beim
Kopieren, auf das Feld ziehen.

Nun genügt ein Doppelklick auf das Ausführen-Symbol oder ein
Druck auf die Taste A, um das Programm zu übersetzen und
dann zu starten (natürlich kann das Übersetzen auch erst durch
einen  separaten  Compiler-Aufruf  erreicht  werden).  Der  Compiler  wird
gestartet und zeigt in etwa folgendes Bild:










Nehmen wir aber  vorsichtshalber  an,  daß  das  Programm  nicht  auf  Anhieb
fehlerfrei ist. In diesem Fall wird der Editor automatisch aufgerufen und zeigt
Ihnen mit dem Cursor die Fehlerposition an. Außerdem ist oben in invertierter
Schrift die Fehlermeldung des Compilers zu sehen. Korrigieren Sie den Text,
und  gehen  Sie  dann  erstmal  wieder  vor,  wie  schon  beschrieben  (Text
speichern, Editor verlassen, Programm ausführen/übersetzen).

Zur Ausführung des Programms ist eigentlich nicht viel zu sagen:  Daß  die
Ausgaben in ein Fenster geschrieben werden, haben Sie schon selbst bemerkt.
Vielleicht haben Sie auch schon ausprobiert, daß das Fenster vergrößert und
verschoben werden kann, wie Sie das so kennen? Die Standardausgaben (über
das Modul InOut) führen immer auf dieses Standard-Fenster, solange Sie un~
ter der Shell arbeiten (und nicht TOSIO extra importieren). Zusätzlich steht
ein Window-Modul zur Verfügung, mit dem Sie auch mehrere Fenster beliebi~
ger Größen handhaben können. (Außerdem gibt's ein Terminal-Modul, das ohne
Fenster arbeitet.)
2.1  Bedienung: Los geht's                                                2 - 12
________________________________________________________


Nun wollen wir das Programm erweitern. Wir befinden uns in
der Shell. Dort aktivieren Sie erneut den Editor. Das geht nun
entweder durch Doppelklick auf das Editieren-Symbol oder die
Taste E.

Zurück im Editor, ändern Sie die WriteString-Anweisungen:



Nun soll erneut übersetzt werden. Dies könnte mit dem Menüpunkt Ende &
Comp veranlaßt werden: Der Editor speichert den Text automatisch, und der
Compiler beginnt mit der Übersetzung. Aber es geht auch noch schneller: Der
Editor erlaubt  es,  den  Compiler  zu  starten,  ohne  den
Text zu speichern und den Editor zu verlassen. Allerdings
wird  dann  auch  mehr  Speicherplatz  benötigt.  Diese
Funktion  wird  im  Menü  durch  Compilieren  oder  durch
Drücken von Alternate-D aktiviert. Wenn allerdings der
Speicher  zum  Übersetzen  nicht  ausreicht,  meldet  der  Compiler  einen
entsprechenden  Fehler  und  Sie  müssen  mit  der  Funktion  Ende  &  Comp.
vorliebnehmen.

Nun wird der Compiler aber einen Fehler melden: Der Cursor steht auf dem
Wort Space, und die Meldung oben weist darauf hin, daß dieser Bezeichner
unbekannt ist. Er muß natürlich erst importiert werden. Dazu fügen Sie hinter
dem InOut-Import noch folgende Zeile ein:



Wenn Sie wieder den Compiler starten, sollte er diesmal alles ohne Fehler
übersetzen. Verlassen Sie diesmal den Editor mit dem Befehl Ende & Ausf.
(Tastenbefehl:  Alternate-A).  Der  Text  wird  automatisch  gespeichert,  der
Compiler übersetzt das Programm (wenn Sie das nicht schon vorher im Editor
getan haben), und dann wird das Programm ausgeführt.

Wenn Ihr Spieltrieb noch nicht erschöpft ist, können Sie ja mal einen Lauf~
zeitfehler im Programm erzwingen (beispielsweise durch eine Division  durch
Null) - was dann passiert, können Sie im Kapitel 2.5 nachlesen.

Spaßeshalber können Sie auch mal das Make (s. Kapitel 2.7) ausprobieren:
Aktivieren Sie im Tools-Menü der Shell das Programm ModRef, oder drücken
Sie dazu die Taste F1. In der dann erscheinenden Selektor-Box wählen Sie ein
Programmodul aus, z.B. das neu erstellte ERSTESPR.M oder auch eines aus
dem DEMO- oder UTILITY-Ordner. Das Programm wird dann nach kurzer Zeit
wieder die Selektor-Box zeigen, worauf Sie entweder  noch  weitere  Module
auswählen oder das Programm durch Klick auf den Abbruch-Knopf beenden. Es
wurde nun eine Datei mit der Endung M2M in dem Verzeichnis erzeugt, wo Sie
das erste Modul ausgewählt haben.
2.1  Bedienung: Los geht's                                                2 - 13
________________________________________________________


Suchen Sie die Datei mit der Endung M2M im Inhaltsverzeichnis, und ziehen
Sie  sie  dann  auf  das  Ausführen-Symbol.  Erst  wird  das  Make-Programm
gestartet,  dann  werden  alle  Module,  die  Sie  vorher  ausgewählt  hatten,
übersetzt und daraufhin das erste Hauptmodul gestartet. Wiederholen Sie dies,
wird  das  Modul  gestartet,  ohne  erneut  übersetzt  zu  werden  -  das  Make
erkennt, daß die Module bereits übersetzt sind.

Allerdings hat die Anwendung des Make hier noch keinen großen Sinn - bei
einzeln zum Ausführen gebrachten Dateien funktioniert diese  Erkennung,  ob
das Modul schon übersetzt ist, sowieso schon direkt von der Shell aus ohne
Verwendung des Make. Und alle Module, die importiert werden, sind Bestand~
teile des Megamax-Systems und deshalb auch schon übersetzt. Erst, wenn
mehrere eigene Module importiert werden, lohnt es sich, das Make intensiver
zu nutzen. Mehr dazu in Kapitel 2.7.

Noch ein Tip zum Starten von Programmen, deren Namen Sie zwar wissen
aber  sie  nicht  erst  umständlich  suchen  wollen,  vielleicht  sogar  erst  noch
übersetzen müssen. Wenn wir Ihnen hier erzählen, Sie sollen beispielsweise
das  Programm  TEXTDEMO  starten,  können  Sie  davon  ausgehen,  daß  sich
dessen Quelltext in dem Ordner DEMO oder UTILITY befindet. So können Sie
nun eine Arbeitsdatei wählen (Taste N) und dort den Quelltextnamen (ohne den
Ordnernamen) eingeben (Taste P). Dieser wird in der Regel aus den ersten
acht Buchstaben des Modulnamens und  der  Endung  ".M"  bei  Hauptmodulen
gebildet. Bei unserem Beispiel also TEXTDEMO.M. Nun drücken Sie einfach die
Taste A oder machen einen Doppelklick aus das Ausführen-Symbol. Dann wird,
falls das Modul noch nicht übersetzt wurde, der Compiler automatisch aktiviert,
daraufhin wird das Programm gestartet.
2.1  Bedienung: Los geht's                                                2 - 14
________________________________________________________

















                               Diese Seite ist leer

























          Trifft dies nicht zu, gehen Sie bitte wie folgt vor:
          Beschaffen Sie ein Blatt Papier (DIN A5). Prüfen Sie, ob das Blatt leer, d.h., frei von
          Buchstaben, ist. Lochen Sie das Blatt mittig. Ein Bürolocher leistet hierbei gute Dienste.
          Heften Sie das von Ihnen erzeugte Blatt auf diese Seite. Sie muß vollständig verdeckt
          werden. Danke.
          Versäumen Sie nicht, diesen Hinweis auf dieser Seite nachzutragen, damit die Betriebssicherheit
          Ihres Handbuchs auch weiterhin gewährleistet bleibt.
2.2  Bedienung: Shell                                                     2 - 15
________________________________________________________


2.2    Shell

Über die Modula-Shell steuern Sie die einzelnen  Komponenten  des  Modula-
Systems: Editor, Compiler, Linker... Die Shell unterstützt Sie dabei nicht nur
durch die GEM-Benutzeroberfläche, sondern erledigt vieles auch automatisch
für Sie - etwa den Aufruf des Editors nach Übersetzungsfehlern oder das
"heimliche" Linken (Binden) eines Moduls vor der Ausführung.


Aufruf der Shell

Wir gehen davon aus, daß Sie sich eine Arbeitsdiskette zusammengestellt ha~
ben  (siehe  Kapitel  2.1).  Wenn  Sie  alle  dort  beschriebenen  Vorbereitungen
getroffen haben, klicken Sie die Modula-Shell MM2SHELL.PRG doppelt an. Das
Laden der Shell kann - je nach Konfiguration - eine Weile dauern, falls weitere
Module resident geladen werden (siehe 2.1). Wenn die Shell betriebsbereit ist,
meldet sie sich mit einer Menüzeile und einem neuen Desktop. Es ist zu beach~
ten,  daß  sich  im  Verzeichnis  der  Shell  zumindest  immer  die  Dateien
MM2SHELL.RSC und MM2SHELL.M2P befinden.


Das Shell-Desktop

Das  Monitor~
bild,  das  die
Shell     Ihnen
zeigt, erinnert
Sie      wahr~
scheinlich  ein
wenig  an  das
GEM-Desktop:
Am     oberen
Rand des Bild~
schirms   gibt
es eine Menü~
zeile; darunter
eine  Arbeits~
fläche, auf der  allerlei  Geräte  'herumstehen'.  Verschaffen  wir  uns  erstmal
einen Überblick über das Inventar:

Die Diskettensymbole erfüllen eine Funktion, die Sie schon vom
GEM kennen - sie repräsentieren die Massenspeicher, also Dis~
ketten, Festplatte oder RAM-Disk. Wenn Sie einen Kasten dop~
pelt anklicken, wird das Inhaltsverzeichnis in einem Fenster angezeigt. Die Na~
men der Symbole werden übrigens von denen des GEM-Desktops übernommen.
2.2  Bedienung: Shell                                                     2 - 16
________________________________________________________



Ebenso  vertraut  sollte  Ihnen  der  Abfalleimer  sein.  Wie  beim
GEM-Desktop kann auch hier alles Mögliche hineingeworfen wer~
den.

Einige Unterschiede zum Desktop gibt es aber doch. Die Inhaltsverzeichnisse
können nur als Text dargestellt werden und nicht auch als Symbole (Icons).
Auch eine Sortierung nach Datum, Größe oder Extension ist z. Zt. nicht mög~
lich (aber wenn Sie wollen, können Sie das selbst ändern - doch dazu mehr im
Kapitel Fünf). Einzelne Dateien lassen sich wie gewohnt selektieren (einfach
anklicken) oder als Objekte auf andere schieben. Die Erweiterung der Selektion
geschieht, wie üblich, durch Festhalten der Shift-Taste beim Anklicken. Auf
dem GEM-Desktop ist es außerdem möglich, mehrere Dateien auf einmal zu
selektieren,  indem  neben  die  Datei-Symbole  bzw.  -Namen  gezeigt  und  mit
festgehaltener Maustaste ein Gummiband um die gewünschten Dateien gezogen
wird. In der Modula-Shell kann nicht neben die Namen geklickt werden - statt
dessen wird diese Multi-Selektion durch Festhalten der Control-Taste erreicht.

Wird eine einzelne Datei selektiert, erscheint ihr Name
übrigens auch in der Anzeigebox für die aktuelle Datei.
Je nachdem, ob es eine ausführbare Datei ist (Program~
me, Module, Make-, Batch- und Parameter-Dateien) oder nicht, wird sie als
CODE oder TEXT eingetragen. Die aktuelle Datei spielt bei der Aktivierung der
Shell-Funktionen über Tastaturkommandos eine Rolle. Sie kann auch manuell
bestimmt werden durch Control-P oder einen Doppelklick auf das Anzeigefeld.

Teilweise wird die aktuelle  Datei  auch  durch  andere  Shell-Operationen  neu
definiert. Beispielsweise wird nach der Compilierung eines Moduls der erzeugte
Code zur aktuellen Code-Datei, so daß sich dann, ohne langes Suchen in den
Disk-Verzeichnissen nach der Datei, das Modul bequem durch Control-A oder
einen Doppelklick auf das Ausführen-Symbol bei gleichzeitigem Festhalten der
rechten Maus-Taste starten läßt.

Hinter dem Resident-Symbol verbirgt sich der Zugriff auf  die
residenten und geladenen Module in der Shell. Durch das Öffnen
(Doppelklick) erhält man ein Fenster, das die z. Zt. geladenen
Module und Programme zeigt - es sind Kopien der ausführbaren Code-Dateien,
die von Disk geladen wurden, um schneller verfügbar zu sein. Genauso wie die
Dateien  der  Disk-Inhaltsverzeichnisse  können  die  geladenen  Module  durch
Ziehen in den Abfalleimer aus dem Speicher (der Shell) entfernt werden oder
umgekehrt  Code-Dateien  aus  Disk-Fenstern  auf  das  Resident-Symbol  oder
dessen Fenster gezogen werden, um sie neu zu laden. Das Resident-Fenster
kann auch durch Drücken der Taste R geöffnet werden.
2.2  Bedienung: Shell                                                     2 - 17
________________________________________________________


Durch  Festhalten  der  Alternate-Taste  beim  Öffnen  des  Resident-Fensters
werden - statt nur der dazugeladenen - alle Module, die zum dem Zeitpunkt
geladen oder resident in der Shell eingelinkt sind, angezeigt - diese residenten
Module können jedoch nicht entfernt werden (das erreichen Sie nur, indem Sie
die Shell, in welche sie alle fest eingebunden sind, verlassen).

Auf das Linken gehen wir in Kapitel 2.6 intensiver ein - hier nur
als Information, daß damit das Linker-Programm gestartet wird,
welches ein Modul so vorbereitet, daß es danach auch außerhalb
der Modula-Shell ausgeführt werden kann. Ein Doppelklick oder Druck auf die
Taste L bewirkt das Linken der aktuellen Arbeitsdatei.

Bleibt noch das Scannen-Symbol, das zur Suche nach Laufzeit~
fehlern dient. Näheres dazu in Kapitel 2.5. Um den Scanner für
die Arbeitsdatei zu starten, kann ein Doppelklick darauf erfolgen
oder die Taste S gedrückt werden.  Nach  einem  erfolgten  Laufzeitfehler  in
einem Programm  kann  der  dabei  geführte  Fehler-Dialog  durch  zusätzliches
Festhalten der Shift-Taste nochmal aktiviert werden.

Schließlich finden Sie auf dem Bildschirm die Symbole Editieren, Compilieren
und Ausführen, deren Bedeutung Sie bereits im Kapitel "Ein erstes Programm"
erfahren haben. Auch sie werden  durch ihre Anfangsbuchstaben E, C und A
über die Tastatur oder durch Doppelklick aktiviert, um die betreffende Opera~
tion mit der aktiven Arbeitsdatei auszulösen.

Die Arbeitsdateien sind ein bequemes Mittel, um abwech~
selnd verschiedene Module zu bearbeiten. Es können bis
zu  zehn  von  ihnen  in  der  Shell  angesprochen  werden.  Die  Arbeitsdateien
werden in kleinen Feldern angezeigt, die durch Anklicken oder durch Drücken
der zugehörigen Tastenziffer angewählt werden können.

Ist  eine  Arbeitsdatei  selektiert  (die  Ziffer  des  Feldes  ist  zur  Kontrolle
invertiert),  kann  ein  bequemer  Doppelklick  auf  die  Symbole  Editieren,
Compilieren, Ausführen, Linken oder Scannen, oder der Druck auf einen der
entsprechenden Anfangsbuchstaben, die gewünschte  Operation  bezüglich  der
Arbeitsdatei  auslösen.   Dieselben   Funktionen   können   durch   zusätzliches
Festhalten der Control-Taste oder der rechten Maus-Taste statt dessen auf
die aktuelle Datei angewandt werden.

Natürlich muß eine Datei nicht erst zur aktuellen oder Arbeitsdatei ernannt
werden, um sie beispielsweise in den Editor zu laden. Wie beim Kopieren von
Dateien können die Einträge aus den Fenstern auch direkt auf die Symbole
gezogen werden.

Ein  Doppelklick  auf  Dateien  ist  auch  möglich:  Je  nach  Art  der  Datei
- ausführbar oder nicht  -  wird  sie  gestartet  oder  in  den  Editor  geladen.
Dateien ohne Extension werden dabei wie Code-Dateien behandelt.
2.2  Bedienung: Shell                                                     2 - 18
________________________________________________________



Zu  Beginn  sind  noch  keine  Arbeitsdatei-
Felder auf dem Desktop vorhanden. Diese
müssen erst durch Drücken der Taste N
oder  Anwählen   des   Menüpunkts   neue
Arbeitsdatei erzeugt werden. Entsprechend
können  sie  mit  lösche  Arbeitsdatei  oder
der Taste Delete wieder entfernt werden.

Ein Modul wird alsdann als Arbeitsdatei bestimmt, indem entweder eine Quell~
textdatei auf ein solches Arbeitsfeld gezogen oder nach Drücken der Taste P
ihr Name manuell eingegeben wird.

Die  restlichen  Funktionen  des  Datei-Menüs  entsprechen  denen  des  GEM-
Desktops,  die  jeweils  rechts  aufgeführten  Tastencodes  dokumentieren  eine
optionale Anwahl über die Tastatur.

Übrigens  können  alle  Objekte  einschließlich  der  Arbeitsdateifelder  auf  dem
Shell-Desktop beliebig positioniert werden, beim Verlassen der Shell werden
dann - auf Wunsch - alle Einstellungen gesichert.


Ausführen von Programmen und anderen Dateien

Zum Ausführen einer Datei ziehen Sie beispielsweise den Eintrag aus dem Datei~
verzeichnis auf das Ausführen-Symbol. Auf diese Weise können Sie sowohl
übersetzte Module ausführen, die dann automatisch mit den benötigten Impor~
ten gebunden werden, als auch komplett gebundene (gelinkte) Programme. Eine
andere Möglichkeit, Dateien zu starten, besteht darin, einen Doppelklick auf
den Eintrag im Fenster durchzuführen.

Es ist auch möglich, Quelltextdateien zum Ausführen zu bringen - in diesem
Fall wird erst nach dem vermutlichen Code-Dateinamen gesucht (dieser wird
aus  dem  Quelltext-Namen  und  den  möglichen  Endungen  der  Code-Module
gebildet); wird er gefunden und ist das Datum der Code-Datei jünger als das
der Quelltextdatei, wird die Code-Datei sofort ausgeführt, ansonsten wird vor~
her der Quelltext automatisch übersetzt. Dies funktioniert auch bei der aktiven
Arbeitsdatei (die ja immer ein Quelltext sein muß), indem ein Doppelklick auf
das Ausführen-Symbol getätigt oder die Taste A gedrückt wird. Voraussetzung
für die Funktionalität dieses Mechanismus ist eine allzeit korrekt eingestellte
Systemzeit im Computer. Wie dies erreicht wird, erfahren Sie im Kapitel 2.7
bei der Anwendung des Make.
2.2  Bedienung: Shell                                                     2 - 19
________________________________________________________


Neben echten Code-Dateien und deren Quelltexten können außerdem Make-,
Batch- und Parameter-Dateien "ausgeführt" werden:

* Wird eine Make-Datei (Endung M2M) ausgeführt, startet die Shell das Make-
  Programm, welches dann prüft, ob Module, die in der Make-Datei aufge~
  führt sind, neu übersetzt werden müssen (siehe Kapitel 2.7). Ist dies der
  Fall, startet die Shell daraufhin den Compiler,  der  dann  alle  notwendigen
  Module übersetzt - es sei denn, es tritt ein Fehler  auf:  Dann  wird  der
  Vorgang abgebrochen, der Fehler im Editor angezeigt, und der Make-Vorgang
  muß nach der Korrektur wiederholt werden.

* Eine Batch-Datei (Endung M2B) enthält eine Reihe von Anweisungen, die mit
  einem Texteditor erstellt werden können. Mit ihr können die Suchpfade für
  Compiler, Editor und Programme sowie die Einträge des Tool-Menüs bestimmt
  und andere Programme  (auch  Compiler,  Linker,  Make)  gestartet  werden.
  Näheres weiter unten.

* Eine Parameter- oder Projekt-Datei hat die Endung M2P und enthält die Ein~
  stellungen der Shell, wie Arbeitsdateien,  Fensterpositionen,  Parameter  für
  Editor, Shell, Compiler usw. Diese Dateien werden von der Shell durch das
  Sichern  der  Einstellungen  erzeugt.  Wird  eine  solche  Datei  "ausgeführt",
  werden alle darin enthaltenen Einstellungen von der Shell übernommen.

Diese Art des Ausführens von Quelltexten, Make-, Batch- und Parameterdateien
ist  auch  bei  den  im  Tools-Menü  eingetragenen  Funktionen  möglich:  Wird
beispielsweise  eine  Datei  DEMO.M2M  als  Tool  eingetragen,  wird  bei  ihrer
Aktivierung über das Tools-Menü der Make-Vorgang eingeleitet, so, als wenn
die Datei auf das Ausführen-Symbol gezogen oder doppelt angeklickt worden
wäre.


Ausführen speziell von Code-Dateien

Vom GEM-Desktop her ist Ihnen bekannt, daß Dateien mit den Endungen APP,
PRG, TOS und TTP ausführbar sind. Diese Programme sind mit anderen Ent~
wicklungssystemen (natürlich auch mit Megamax Modula-2) erstellt worden und
haben alle ein einheitliches Dateiformat, das vom Betriebssystem (GEMDOS)
verstanden wird, und somit können sie vom Desktop oder auch von anderen
Benutzeroberflächen (Shells) aus bequem gestartet werden. Diese Programme
haben alle erforderlichen Routinen fest eingebunden und definieren beispiels~
weise auch ihren eigenen Stack-Bereich.

Vom  Modula-Compiler  übersetzte  Module  sind  dagegen  noch  nicht  gelinkt
(gebunden), so daß sie auch nicht ohne weiteres vom GEM-Desktop oder einer
anderen Shell gestartet werden können, weil sie in der Regel dieses fremde
Format nicht kennen. Deshalb verdienen diese Code-Module  auch  keine  der
bekannten  Programm-Endungen.  Ausführbar  sind  die  übersetzten  Module
2.2  Bedienung: Shell                                                     2 - 20
________________________________________________________


(natürlich nur die Haupt- und Implementations-, jedoch nicht die Definitionsmo~
dule) unter der Shell aber trotzdem, dank des sogenannten Loaders, welcher
ein in der Shell eingebundenes Modul darstellt, das eine dynamische Bindung
der benötigten Module und andere Vorbereitungen, beispielsweise das Anlegen
eines Stacks, automatisch durchführt.

Die übersetzen Code-Module können, entsprechend den gelinkten Programmen,
die Endungen MOD (analog zu APP und PRG), MOS (TOS) oder MTP (TTP)
tragen.  Wird  also  eine  Datei  mit  einer  dieser  Endungen  unter  der  Shell
ausgeführt, wird sie wie die gelinkten Programme unter dem  GEM-Desktop
behandelt: Bei MOS-Dateien wird der TOS-Modus (weißer Hintergrund, Maus
aus, Blinke-Cursor an) aktiviert, bei MTP-Dateien wird zusätzlich nach einer
Kommandozeile  (Argumentzeile)   für   das   Programm   gefragt.   Wird   ein
Code-Modul an den Linker zum Binden übergeben, erzeugt dieser passend zur
Endung  den  entsprechenden  Programmnamen  (Bsp:  "TEST.MOS"  wird  zu
"TEST.TOS").

Falls Ihnen übrigens andere Endungen besser vertraut sind (OBJ, OBM, SYM,
usw.),  können  Sie  in  Kapitel  Fünf  nachlesen,  wie  einfach  Sie  dies  dem
Megamax-System beibringen können.

Der Linker kennt noch eine weitere Endung: Aus MAC  erzeugt  er  gelinkte
Dateien der Endung ACC; dies ist vorteilhaft, wenn Sie Accessories erzeugen
wollen - diese dürfen in der Regel nicht ausgeführt, sondern nur als ACC-
Dateien beim Booten des Rechners vom GEM aktiviert werden (es sei denn,
Sie verwenden die Funktion PrgCtrl.Accessory() zur Abfrage, ob das Programm
als normale Anwendung oder als Accessory gestartet wurde).

Durch das Festhalten der Shift-Taste beim Starten erhalten Sie die Möglichkeit
zur Eingabe einer Argumentzeile (Command Line) auch bei Programmen der
Endungen MOD, MOS, APP, PRG und TOS.

Ein Problem, das noch nicht ganz zufriedenstellend gelöst wurde, ist die Wahl
des aktuellen Verzeichnisses für zu startende Programme. So gibt es Pro~
gramme, die als Hilfsprogramme der Shell dienen und  die  oft  gerne  stan~
dardmäßig auf den in der Shell aktuellen Pfad (der durch das oberste offene
Disk-Fenster  bestimmt  wird)  zugreifen  wollen,  beispielweise,  wenn  sie  den
GEM-Datei-Selektor anzeigen. Andererseits gibt es Anwendungen, die weitere,
dazu gehörende Dateien nachladen wollen, wie zum Beispiel GEM-Resource-
Dateien (Endung RSC). Damit sie diese Dateien finden, ist es in der Regel so
zu lösen, daß sie im Verzeichnis gesucht werden, in dem auch das Programm
selbst steht. Davon macht beispielsweise auch die Modula-Shell Gebrauch: Sie
sucht bei ihrem Start die Dateien MM2SHELL.RSC und MM2SHELL.M2P im zu
dem Zeitpunkt aktuellen Verzeichnis,  welches  normalerweise  auch  dasjenige
ist, in welchem die Shell selbst steht, weil ja auch im GEM-Desktop das ent~
sprechende Fenster obenauf offen liegen muß, damit die Shell gestartet werden
kann.
2.2  Bedienung: Shell                                                     2 - 21
________________________________________________________


Nun gibt es aber auch beim GEM-Desktop die Möglichkeit, Programme nicht
aus dem vordersten, aktiven Fenster zu starten: Zielt man beim Starten auf
ein Programm in einem inaktiven Fenster und hält dabei die rechte Maus-Taste
fest, wird das Programm gestartet, während das vordere Fenster den aktuellen
Pfad  bestimmt.  Dies  machte  sogar  den  Entwicklern  des  TOS  bei  ATARI
Schwierigkeiten, denn je nach Version des TOS gibt es verschiedene Resultate:
Einmal wird das Programm überhaupt nicht gestartet, ein anderes Mal kann es
seine RSC-Datei nicht finden.

Die Megamax-Shell geht nun so vor: Wird das Programm von einem Fenster
gestartet,  wird  immer  der  Pfad  zum  aktuellen,  von  dem  das  Programm
stammt. Ebenso wird verfahren, wenn eine Arbeitsdatei gestartet wird. Wird
die  aktuelle  Datei  aufgerufen,  hängt  der  aktuelle  Pfad  vom  eingegebenen
Dateinamen  ab:  Ist  ein  Pfadname  im  Dateinamen  enthalten,  wird  dieser
aktiviert. Ist kein Pfadname enthalten, wird wiederum derjenige verwendet, von
dem das Programm gestartet wird (das funktioniert, weil die Programme dann
in den Ordnern gesucht werden können). Dies macht bei der aktuellen Datei
nur dann einen Unterschied, wenn ihr Name manuell eingegeben wurde (durch
Doppelklick  auf  dessen  Feld  oder  mittels  Control-P);  beim  Benennen  der
aktuellen Code-Datei durch Anklicken im Fenster oder nach einem Make- oder
Übersetzungsvorgang wird immer der vollständige Pfadname mit übernommen.

Wollen Sie also ein bestimmtes Programm starten, das Sie nicht erst in den
Ordnern suchen wollen, brauchen Sie nur die aktuelle Datei zu  bestimmen,
indem Sie den Namen des Programms (mit Endung, aber ohne Pfad) eingeben
(Control-P) und dann starten (Control-A). Wollen Sie gar erreichen, daß ein
Programm  einen  bestimmten  aktuellen  Pfad  erhält,  kann  dieser  bei  der
Bestimmung der aktuellen Datei als Pfad mit eingegeben werden. Dann wird
dieser Pfad zum aktuellen, das Programm wird jedoch, wenn es dort nicht
vorhanden  ist,  weiterhin  in  den  anderen  Ordnern  gesucht  und  von  dort
gestartet.

Bei den Systemprogrammen (Compiler, Linker, Make, Editor) und den unter
dem Tools-Menü eingetragenen Programmen verhält es sich noch etwas anders.
Da die Systemprogramme als feste Bestandteile des Entwicklungssystems mit
der Shell  in  besonderer  Weise  kommunizieren  bzw.  die  Tools  oft  ähnliche
Funktionen erfüllen,  kann  ihnen  der  aktuelle  Pfad  praktisch  egal  sein.  Aus
diesem Grund wird bei ihren Aufrufen normalerweise kein neuer aktueller Pfad
eingestellt, statt dessen bleibt der Pfad der Shell (oberstes Fenster) aktiv.
Damit nun aber auch andere Editoren oder Tools ihre benötigten Dateien (z. B.
RSC) nachladen können, gibt es auch hier die Möglichkeit, ihren aktuellen Pfad
zu definieren: Ist ein Systemprogramm oder ein Tool mit einem Pfadnamen
eingetragen, wird dieser Pfad beim Start aktiviert, ansonsten wird der Pfad
der Shell beibehalten.
2.2  Bedienung: Shell                                                     2 - 22
________________________________________________________


Um allgemein das Wechseln des Aktuellen Pfades beim Start eines Programms
zu verhindern, muß die Alternate-Taste bei Aktivierung der Ausführen-Funktion
festgehalten werden.


Programmaufruf und -abbruch bei gelinkten Programmen

Wird   ein   gelinktes   Programm   ausgeführt,   geschieht   dies,   wie   vom
GEM-Desktop her gewohnt: Das Programm wird in den Speicher geladen, falls
dies nicht schon vorher geschehen ist (siehe Laden von Code-Dateien), dann
wird  dessen  BSS-Bereich  (Speicher  für  die  globalen  Variablen)  gelöscht,
zuletzt  wird  es  gestartet.  Endet  das  Programm,  wird  zur  Megamax-Shell
zurückgekehrt.

Tritt ein fataler Fehler im aufgerufenen, gelinkten Programm auf, so daß eine
68000-Exception (Bus-Fehler, Adreß-Fehler und weitere von dem Programm
nicht abgefangene Fehler) ausgelöst wird, erscheint statt der vom Desktop-
Start gewohnten Bömbchen die Scanner-Box (siehe Kapitel 2.5), in der aber
dann  keine  Lokalisation  der  Fehlerstelle  über  Back  und  Frwd  möglich  ist.
Wählen Sie dann Quit, finden Sie sich in der Shell wieder. Dann kann es aber
sein, daß die Maus nicht  mehr  sichtbar  ist  oder  andere  unsinnige  Effekte
eintreten. Wenn die Shell noch auf Eingaben reagiert, verlassen Sie die Shell,
z. B. mit Control-Q. Oft stellt dann  das  GEM-Desktop  den  Normalzustand
wieder her, so daß Sie die Megamax-Shell erneut starten können. Bei solchen
Abstürzen von Progammen ist es aber in der Regel immer das Sicherste, so
bald wie möglich einen Neustart des Rechners, beispielsweise durch Drücken
des RESET-Tasters, zu veranlassen, weil es möglich ist, daß das fehlerhafte
Programm auch Speicherbereiche, die dem TOS oder der Shell reserviert sind,
unkontrollierbar  überschrieben  hat,  was  sich  teilweise  erst  sehr  spät
bemerkbar macht.


Das Binden der Module

Wird ein vom Compiler übersetztes Modul gestartet, müssen zuerst die von
ihm importierten Module dazugebunden (gelinkt) werden.  Dies  wird  von  der
Prozedur CallModule des Loader-Moduls, die die Shell zum Starten sowohl von
gelinkten Programmen als auch von ungelinkten Modulen aufruft, automatisch
erledigt: Jedes benötigte Modul wird in den Speicher geladen, wird ein Modul
von  mehreren  anderen  importiert,  wird  es  selbstverständlich  nur  einmal
geladen.  Danach  werden  die  Module  gebunden,  das  heißt,  die  Referenzen
zwischen den Modulen (dies sind die importierten Prozeduren und Variablen)
werden fest verkettet. Diesen Vorgang nennt man Load-Time-Linking, weil das
Binden (Linken) der einzelnen Objekt-Module bei jedem Laden in den Speicher
von neuem erfolgt. Dem gegenüber steht das einmalige Linken im voraus, bei
dem das Ergebnis als eine Datei (gelinktes Programm) erzeugt wird.
2.2  Bedienung: Shell                                                     2 - 23
________________________________________________________


Auf den ersten Blick nun erscheint es ineffektiv, bei jedem Start das Linken
durchzuführen,  anstatt  dies  einmal  zu  tun:  Wird  das  Programm  mehrmals
nacheinander ohne Änderungen gestartet, vergeht viel mehr Zeit  durch  das
wiederholte  Laden  der  einzelnen  Code-Module  statt  der  einen  gelinkten
Programmdatei. Dies trifft aber nur bedingt zu. Ein Vorteil im dynamischen
(Load-Time-) Linken liegt darin, daß die Fehlerbehandlung (Debugging) einfacher
zu  gestalten  ist,  zweitens  können  so  mehrere,  abwechselnd  gestartete
Progamme  leichter  Informationen  untereinander  austauschen,  und  zu  guter
Letzt ist es oft auch zeitsparender. Das kommt daher:

Der Loader (bzw. dessen Funktion CallModule) lädt jedes benötigte Modul nur
einmal, auch wenn es von mehreren Modulen importiert wird. Dies ist sinnvoll
und  findet  bei  auch  jedem  normalen  Linker  anderer  Entwicklungssysteme
Verwendung.

Die Megamax-Shell besteht nun wiederum selbst aus vom Megamax-Compiler
übersetzten Modulen, die lediglich durch den Linker in eine Datei zusammengefügt
wurden. Nun bietet es sich an, diese schon im Speicher befindlichen Module bei
Bedarf  mitzubenutzen,  genauso  wie  dies  mit  den  nachgeladenen  Modulen
geschieht. Bedingung ist lediglich, daß das Loader-Modul, das selbst ja auch
Bestandteil  der  Shell  ist,  ausreichend  Informationen  über  die  in  der  Shell
befindlichen Module erhält. Dies wurde beim Linken der Shell durch eine beson~
dere Einstellung (Linken ohne Optimierung) erreicht.

Wird also der Loader aufgerufen, ein Modul zu starten (z. B. durch Ansprechen
der Ausführen-Funktion der Shell), geht er wie bereits oben beschrieben vor:
Zuerst wird nachgesehen, ob sich das geforderte Modul schon im Speicher
befindet. Normalerweise ist dies beim Hauptmodul noch nicht der Fall,  also
wird es nachgeladen und der Loader merkt sich, daß dieses Modul nun geladen
ist. Dann wird nachgesehen, welche Module importiert werden. Bei denen wird
genauso verfahren: Ist das Modul noch nicht im Speicher, wird es geladen und
dessen Importe ebenfalls berücksichtigt.

Ist ein Modul schon im Speicher, wird es nicht weiter verfolgt - in diesem Fall
kann  davon  ausgegangen  werden,  daß  alle  seine  Importe  ebenfalls  schon
geladen sind. Es ist also nicht möglich, auch nicht mit den Lade-/Entlade-
Funktionen des Loader-Moduls bzw. der Shell,  daß  am  Ende  ein  Modul  im
Speicher verbleibt, dessen Importe nicht ebenfalls alle geladen sind!

Nach diesen Lade-Regeln nun werden die  in  der  Shell  vorhandenen  Module
immer als bereits geladen (speziell: resident) behandelt. Daraus folgt, daß ein
Modul, das nur Module importiert, die schon in der Shell befindlich eingebunden
sind, praktisch keine Ladezeit mehr hat, weil lediglich das Hauptmodul selbst
von Disk geladen werden muß - das Binden dieses Moduls mit denen der Shell
geht so schnell, daß Sie davon nichts merken.
2.2  Bedienung: Shell                                                     2 - 24
________________________________________________________


Nach der Bindung aller Module werden zuerst, wie bei gelinkten Programmen,
alle globalen Variablen gelöscht (Pointer auf NIL, REALs auf 0.0) und dann alle
Modulkörper aufgerufen, das am tiefsten liegende von den anderen importierte
Modul  wird  zuerst,  das  oberste,  von  der  Shell  ausgewählte  Modul  zuletzt
initialisiert. Bei zirkularen Importen (A importiert B, B wiederum A) ist die
Reihenfolge undefiniert und kann jederzeit wechseln.

Wollen Sie die Möglichkeit nutzen, daß mehrere durch CallModule gestartete
Anwendungen (Module) Daten über gemeinsam importierte Module austauschen
(shared  data),  müssen  Sie  verhindern,  daß  diese  gemeinsamen  Module
jedesmal neu  initialisiert  werden  und  neuen  Speicherplatz  für  ihre  globalen
Variablen  erhalten.  Das  erreichen  Sie,  indem  Sie  solche  Module  mit  einer
besonderen Compiler-Direktive ($Y+, siehe Kapitel 3.4) übersetzen.

Während der gesamten Initialisierungsphase und beim Start des Hauptmoduls
wird ein Stack verwendet, dessen Größe in Info/Umgebung unter Stackgröße...
(für Load-Time-Linking) einstellbar ist. Tritt während des Programmlaufs ein
Stack-Überlauf-Fehler auf, kann der Stack also ohne Neuübersetzung für den
nächsten Start verändert werden.  Die  Systemprogramme  (Compiler,  Linker,
Make sowie die Editoren GME und GEP ED) verwenden übrigens eine eigene,
                                          _
fest in der Shell definierte Stackgröße.
2.2  Bedienung: Shell                                                     2 - 25
________________________________________________________


Resident-Laden von Code-Dateien

Wenn ein gestartetes Modul abgelaufen ist, wird es wieder aus dem Speicher
entfernt. Auch die von ihm importierten Module, die noch von der Diskette
nachgeladen wurden, bleiben natürlich nicht im Speicher - bei einem  neuen
Start des Moduls wird alles erneut geladen. Um bei häufiger Benutzung eines
Moduls diese Ladezeiten zu eliminieren, können Sie Module in den Speicher
laden.   Dazu   dient   das   Resident-Symbol   auf   der   Arbeitsfläche.   Das
Resident-Symbol  funktioniert  ganz  ähnlich  wie  die  Diskettensymbole.  Sie
können...

* einen Dateieintrag auf das Ladesymbol schieben, um das Modul
in den Speicher zu laden (Control-R lädt die aktuelle Datei). Es
ist auch möglich, gelinkte Programme auf diese Weise zu laden;

* das Ladesymbol doppelt anklicken, um ein Fenster mit dem Verzeichnis der
geladenen Module zu öffnen;

* Einträge aus diesem Fenster mit der Maus auf das Ausführen-Symbol schie~
ben oder doppelt anklicken, um sie auszuführen. Allerdings ist es auch möglich,
ein Modul aus einem ganz normalen Dateifenster zur Ausführung zu bringen -
die Shell (der Loader) überprüft, ob das Modul schon geladen ist, und führt
ggf. die geladene Version aus.

* Außerdem ist es möglich, Einträge aus dem Verzeichnis der geladenen Mo~
dule in den Abfalleimer zu schieben, um sie wieder aus dem RAM zu löschen.
Beachten Sie aber, daß das Ladesymbol keine normale RAM-Disk darstellt -
beim Laden werden die Module bereits für die Ausführung vorbereitet (gelinkt);
daher ist es nicht möglich, ein geladenes Modul auf ein Diskettensymbol zu
schieben oder an den Linker zu übergeben!

Ein anderer Weg, Module und gelinkte Programme resident laden zu lassen, ist
das Eintragen eines LOAD-Kommandos in eine Batch-Datei (s. Abschnitt weiter
unten in diesem Kapitel). Dies ist eine bequeme Möglichkeit, regelmäßig benötigte
Module resident in den Speicher zu laden, solange man sich in der Modula-
Shell befindet.

Die  so  geladenen  Module  werden  zwar  in  die  schon  residenten  Module
eingebunden (gelinkt), jedoch nicht intitialisiert! Die Initialisierung mit  Aufruf
der Modulkörper wird weiterhin so vorgenommen, wie unter Binden der Module
beschrieben, also als wenn sie jedesmal bei Bedarf doch  von  Disk  geladen
werden würden.

Zum Schluß noch ein Tip: Während der Programmentwicklung können Sie den
Entwicklungszyklus (Edieren -  Übersetzen  -  Testen)  deutlich  beschleunigen,
falls Ihr Programm Module importiert, die nicht bereits in der Shell vorhanden
2.2  Bedienung: Shell                                                     2 - 26
________________________________________________________


sind (das merken Sie an den Diskettenzugriffen vor jedem Programmstart):
Dann sollten Sie die importierten Module laden. Das Programm, an dem Sie
gerade arbeiten, sollte dagegen nicht geladen sein - die geladene Version hat,
wie oben gesagt, immer Vorrang vor  dem  neu  übersetzten  Modul  auf  der
Diskette.

Das Laden ist meist dem Ablegen eines Moduls in der RAM-Disk vorzuziehen:
Ein Modul aus der RAM-Disk wird zur Ausführung jeweils ein zweites Mal in
den RAM kopiert und belegt dann doppelten Platz. Allerdings wird beim Laden
bereits Platz für die globalen Variablen reserviert, der belegt bleibt, solange
das Modul im RAM verbleibt. Dies wiederum macht sich bei wenigen Program~
men deutlich bemerkbar (beispielsweise bei dem Programmeditor TEMPUS von
CCD).


Laden gelinkter Programme

Das Laden von gelinkten Programmen wird prinzipiell durch eine Sonderfunktion
des  GEMDOS  ermöglicht.  Aufgrund  einer  konzeptionellen  Schwäche  bei
besagter Funktion ist aber deren Anwendung leider nicht so "idiotensicher" wie
die des Ladens von Megamax-Modulen.

Das Problem ergibt sich bei der Reservierung des Stacks für die Programme:
Ein gelinktes Programm, das normal gestartet wird, wird an den Beginn des
größten freien Speicherbereichs geladen. Wird es dann aufgerufen, erhält es
erstmal den gesamten freien Speicher hinter dem Programmcode für sich als
reservierten Speicher. Daraufhin berechnet es den für sich selbst benötigten
Speicher und gibt den Rest wieder frei. Der selbst benötigte Speicher besteht
in der Regel aus dem Platz für die globalen Variablen und dem Stack des
Programms.

Wird ein solches Programm nur geladen, muß der Loader, der dies organisiert,
dafür sorgen, daß nur so viel Platz für das Programm reserviert bleibt, wie es
später beim Start benötigen wird, damit der Rest des Speichers frei bleibt für
weitere Anwendungen. Aufgrund der Konventionen aber  muß  das  Programm
erwarten können, daß es den benötigten Speicher für die Variablen und den
Stack  direkt  hinter  dem  Programmcode  vorfindet  (für  die  Experten:  Die
Relozierung, die das GEMDOS beim Laden vornimmt, nimmt auch sofort die
Adreßbestimmung der globalen Variablen im BSS-Segment - welches in der
Regel direkt hinter dem Programmcode oder dem DATA-Segment liegt - vor,
so daß dieser Bereich später nicht mehr an eine andere Stelle verschoben
werden kann). Hier liegt das Problem:  Es  ist  zwar  allgemein  möglich,  den
benötigten Platz für die globalen Variablen zu ermitteln, die Stack-Größe aber
kann  nicht  vorausgesehen  werden.  So  muß  also  beim  Laden  abgeschätzt
werden, wieviel Platz der Stack später benötigen wird. Zuviel Platz kann dem
Programm nicht schaden, nur wird der Platz ja schon beim Laden reserviert,
so daß der verbleibende freie Speicher ggf. unnötig eingeschränkt wird.
2.2  Bedienung: Shell                                                     2 - 27
________________________________________________________


Ist der Stack zu klein gewählt, ist es möglich (aber nicht sicher), daß das
geladene  Programm  während  seines  Aufrufs  fehlerhaft  arbeitet  oder  gar
abstürzt (Programm reagiert nicht mehr auf Eingaben, oder es erscheinen die
Bömbchen und das Programm kehrt in die Shell zurück).

Gegebenenfalls  muß  also  zuerst  ein  geladenes  Programm  mit  Vorsicht
angewendet werden (jedenfalls sollte es bei Unsicherheit nicht mit wichtigen
Originaldaten arbeiten, die es ja zerstören könnte).

Die meisten Fremdprogramme verwenden einen Stack von 8 bis 16 KByte (auch
Tempus kommt beispielsweise mit einem Stack von 8KB, =8192, zurecht). So
reicht  es  oft  aus,  zur  Sicherheit  den  Stack  beim  Laden  in  dieser  Größe
vorzusehen. Erst,  wenn  sich  ungewöhnliche  Effekte  bei  der  Benutzung  der
geladenen Programme zeigen, sollte der Stack jeweils vor dem erneuten Laden
durch Verdoppelung erhöht werden.

Die Bestimmung des Stacks  beim  Laden  von  gelinkten  Programmen  erfolgt
durch den Wert, den auch der Loader beim Start von Modulen verwendet. Er
kann in den Umgebungsinformationen unter Stack-Größe für Load-Time-Linking
bestimmt oder durch die Anweisung STACKSIZE in Batch-Dateien, am besten
direkt vor dem Laden des Programms mit LOAD, auf einen besonderen Wert
gesetzt werden.
2.2  Bedienung: Shell                                                     2 - 28
________________________________________________________


Die Menüzeile der Shell

Die  Menüzeile  am  oberen  Bildschirmrand  bietet  die  Menüpunkte  MM2Shell,
Datei, Parameter, Info und ggf. Tools an. Unter MM2Shell erreichen Sie wie
üblich die Accessories sowie eine Meldung über die Version der Shell. Der
Menüpunkt Datei wurde schon weiter oben behandelt.

Unter Parameter finden sich:

Shell: Siehe unten.
Editor: Siehe Kapitel 2.3
Compiler: Siehe Kapitel 2.4
Linker: Siehe Kapitel 2.6
speichern: Sichert die Einstellungen aller Parameter, der Symbol- und Fenster~
  positionen  und  der  Umgebungseinstellungen,  jedoch  nicht  den  Status  der
  geladenen Module, der über die Menüzeile abrufbaren Tools und der Such~
  pfade  (diese  Einstellungen  sind  über  die  Batch-Dateien  bestimmbar).  Die
  Einstellungen  werden  in  der  Datei  gesichert,  die  zu  dem  Zeitpunkt  als
  Parameterdatei unter Parameter/Shell... eingestellt ist.

Die Raute bei den Tastenangaben im Parameter-Menü zeigt übrigens an, daß
diese Funktionen mit der Alternate-Taste in Verbindung mit dem Buchstaben zu
erreichen sind, während der Pfeil für die Control-Taste steht.


Unter Info finden sich:

Umgebung: Siehe unten.
Hilfe: Zeigt den Inhalt der Textdatei MM2SHELL.HLP an, falls sich diese im
  Verzeichnis der Shell befindet.


Unter Tools können Sie bis zu zehn eigene ausführbare
Dateien eintragen (mittels der Anweisung Tool in  einer
Batch-Datei). Diese erscheinen dann  unter  dem  Tools-
Menüpunkt und können auch über die Funktionstasten an~
gewählt werden.
2.2  Bedienung: Shell                                                     2 - 29
________________________________________________________


Die Shell-Parameter (Parameter/Shell...)

Erzeuge Fenster:
Wurzel öffnet  Fenster  bei
Doppelklick  in   gewohnter
Weise.  Der  aktuelle  Pfad
kann  statt  dessen   ent~
weder  durch  die  hiesige
Standardeinstellung    oder
durch Festhalten der Shift-
Taste   beim   Doppelklick
geöffnet werden.

Kopier- und Löschbestätigung bestimmen, ob bei den entsprechenden Dateiope~
rationen eine Bestätigung gefordert werden soll.

Abbruch mit Control-C: Ist diese Option aktiv, können von der Shell gestartete
Programme mit Control-C abgebrochen werden, während sie Ein- oder Ausga~
ben über die Module TextWindows oder InOut durchführen. Auch ist es dann
möglich, mit Control-Enter Programme zu jeder Zeit abzubrechen - dies sollte
aber nur dann geschehen, wenn Control-C nicht wirkt und das Programm nicht
gerade Betriebssystemaufrufe (z.B. Zugriff auf die Disk oder Grafikausgaben
auf dem Bildschirm) durchführt, da es sonst zu Fehlverhalten des Systems
kommen kann. Nähere Informationen im Definitionstext des Moduls UserBreak.

Anwender eines Drucker-Spoolers oder der Flexdisk sollten die Option Maximaler
Kopierpuffer gegebenenfalls deaktivieren, ansonsten bietet es sich fast immer
an, diese Option zu nutzen, denn dadurch wird bei Kopiervorgängen fast der
gesamte  Speicherplatz  verwendet,  um  den  Kopiervorgang  möglichst  schnell
durchzuführen.

Unter Make wird der Name des Make-Programms eingetragen - dies ist in der
Regel MM2Make.

In Temp. Pfad sollte ein Ordnername eingetragen werden, in dem die Shell und
die Hilfsprogramme kurzzeitig kleine Dateien ablegen können. So  legt  Make
dort beispielsweise die Steuerdatei der evtl. zu übersetzenden Module für den
Compiler ab. Nach Möglichkeit sollte dieser Pfad auf einem schnellen Gerät
liegen, also eher auf einer RAM-Disk als einer Diskette - ein Pfad auf der
Harddisk reicht natürlich auch aus.

Die Batch-Datei (mit der Endung M2B) ist diejenige, die ausgeführt wird, wenn
die  darunter  angegebene  Parameterdatei  (teilweise  auch  als  Projekt-Datei
bezeichnet) aktiviert oder "ausgeführt" wird. Diese  wiederum  kann  aktiviert
werden, indem sie - vorausgesetzt, sie hat die Dateiendung M2P - auf ge~
wohnte  Weise  (Doppelklick,  Ziehen  auf  das  Ausführen-Symbol,  Starten  als
Tool)  "ausgeführt"  wird.  Einen  Sonderstatus  genießt  die  Parameterdatei
2.2  Bedienung: Shell                                                     2 - 30
________________________________________________________


MM2SHELL.M2P: Sie wird beim Starten der Shell, wenn sie  sich  in  deren
Verzeichnis befindet, automatisch ausgeführt. Somit muß die Batch-Datei, die
beim Start der Shell ausgeführt werden soll, nicht zwingend "MM2SHELL.M2B"
heißen, sondern lediglich als Batch-Datei der Parameterdatei MM2SHELL.M2P
definiert sein.

Um eine neue Parameter- oder Batch-Datei zu erstellen, können Sie folgen~
dermaßen  vorgehen:  Tragen  Sie  eine  beliebige  Datei  der  Endung  M2B  als
Batch-Datei und ebenso eine der Endung M2P (z. B. MM2SHELL.M2P für die
Autostart-Parameter) als Parameterdatei ein. Dann verlassen Sie den Shell-
Parameter-Dialog und wählen Parameter/speichern... an. So werden die aktu~
ellen Einstellungen unter der gewählten Parameterdatei gesichert.


Die Umgebungsinformationen (Info/Umgebung...)

Letzter  Code/Länge  infor~
mieren über die vom letzten
Compileraufruf erzeugte Code-
Datei und dessen Länge.

Normalerweise    wird    der
aktuelle   Pfad   durch   das
oberste,   geöffnete   Disk-
Fenster bestimmt. Ist jedoch
keins offen,  kann  der  Pfad
hier abgelesen oder auch geändert werden. Das Ändern des Pfades hat keinen
Erfolg, wenn ein Fenster geöffnet ist - dieses hat dann Vorrang.

Die Default-Make-Datei wird aktiviert, wenn in der Shell die Taste M gedrückt
wird oder wenn vom Editor (GEP_ED oder GME) aus die Make-Funktion ange~
wählt wird. Das Aktivieren einer Make-Datei bewirkt den Aufruf des Make-
Programms, welches dann aufgrund der Informationen aus der Make-Datei (mit
Endung M2M) prüft, ob Dateien zu übersetzen sind und daraufhin dann den
Compiler dazu aufruft. Näheres in Kapitel 2.7.

Die Stack-Größe für das Load-Time-Linking wird den Anwendungsmodulen zur
Verfügung gestellt, wenn sie unter der Shell gestartet werden (gelinkte Program~
me haben bereits intern eine feste Einstellung - beim Linken von Megamax-
Modulen kann dieser Wert ebenfalls bestimmt werden, allerdings in den Lin~
ker-Optionen). Der anfangs eingestellte Wert von 16 K Bytes kann zu klein
sein, wenn das Programm rekursiv arbeitet oder große Datenstrukturen als
lokale Variablen verwendet (Sie erfahren dies dann während des Programm~
laufs durch die Fehlermeldung "Stack-Überlauf").

Taste nach TOS-Programmen: Wartet beim Ende von TOS-Programmen auf
einen Tastendruck, damit eventuelle Ausgaben noch gelesen werden können.
2.2  Bedienung: Shell                                                     2 - 31
________________________________________________________


Der aktuell freie Speicherplatz wird in zwei Werten angezeigt. Der linke gibt
den größten  zusammenhängenden  Bereich,  der  rechte  den  gesamten  freien
Platz an.


Tasten-Funktionen

Zusammenfassend haben folgende Tasten in der Shell eine Funktion:

Anfangsbuchstaben der Symbole: Sie bearbeiten alle die jeweils aktive Arbeits~
datei, es sei denn, es wird zusätzlich die Control-Taste gedrückt - dann wird
stattdessen die aktuelle Datei bearbeitet.

  A        Ausführen (von Programmen, Modulen, Make, Batch, Projektdateien)
                 Wird dabei Shift festgehalten, kann eine Argumentzeile (wie
                 bei  TTP  bzw.  MTP-Programmen)  eingegeben  werden,  beim
                 Festhalten von Alternate bleibt der aktuelle Pfad erhalten.
  C        Compilieren (Übersetzen)
  +         Compilieren, dann Ausführen
  E        Laden der Datei in den Editor
  L         Linken (Binden der Module zu einem Programm)
  S        Aktivieren des Scanners
                 Falls  vorher  bei  einem  Programmaufruf  ein  Laufzeitfehler
                 auftrat und die Scanner-Dialogbox erschien, kann durch Ein~
                 gabe von Shift-S der letzte Dialog wiederholt werden, um eine
                 andere Textposition anzuscannen (siehe Kapitel 2.5).
  P        Eingabe der Arbeits- oder aktuellen Datei über Tastatur.

Weitere spezielle Funktionen, die nicht aus den Menüzeilen ersichtlich sind:

  M        Make-Vorgang mit der Default-Make-Datei einleiten.
  Ctrl-R   Laden der aktuellen Code-Datei.
  R        Anzeige der geladenen Module und gelinkten Programme.
  Alt-R    Anzeige aller im Speicher vorhandenen (residenten) Module.

Bleiben noch folgende versteckte Funktionen:

  Esc      Neuanzeige des Inhalts des obersten Fensters, z.B. nach Wechseln
            einer Diskette;
            Während des Starts der Shell kann durch Druck auf diese Taste
            verhindert werden, daß Programme durch den Start-Batch geladen
            werden.
  Home    Schließt das Verzeichnis des aktiven Fensters.
  Clr       (Shift-Home)  Schließt  das  aktive  Fenster.  Werden  beide  Shift-
            Tasten festgehalten, werden alle Fenster geschlossen.
  Ctrl-Q   Beenden der Shell ohne Nachfrage zum Sichern der Einstellungen.
2.2  Bedienung: Shell                                                     2 - 32
________________________________________________________


Batch-Dateien

In Batch-Dateien können häufig benötigte Shell-Operationen und -Einstellungen
beschrieben und dann jederzeit zur Ausführung gebracht werden. Außerdem
werden hiermit die Suchpfade der Dateien für Shell, Editor, Compiler, Linker
und Make eingegeben. Die Batch-Datei ist ein normaler ASCII-Text, der alle
Anweisungen  im  Klartext  enthält,  daher  können  Sie  diese  Datei  mit  dem
mitgelieferten Editor bearbeiten.

Eine besondere Batch-Datei ist diejenige, die in den Shell-Parametern unter
Batch-Datei  eingetragen  ist:  Sie  wird  automatisch  beim  Start  der  Shell
ausgeführt. Üblicherweise enthält diese Datei Anweisungen, um Module (auch
gelinkte Programme) zu laden und um vor allem die Suchpfade zu bestimmen,
damit überhaupt ein Arbeiten in der Shell möglich ist.

Im  folgenden  wird  zunächst  die  Syntax  der  Batch-Dateien  beschrieben  (in
Backus-Naur-Form, siehe Anhang A.6); anschließend erläutern wir die Funktion
der einzelnen Anweisungen:

Syntax der Batch-Dateien

anweisung  =    IF SHELLSTART anweisung <cr> |
                    _
                  WAIT text <cr> |
                  * text <cr> |

                  SETPATH pfad <cr> |
                  SETDRIVE laufwerk <cr> |
                  SETDIR pfad <cr> |

                  DELETETOOLS <cr> |
                  TOOL dateiname <cr> |

                  LOAD dateiname <cr> |
                  UNLOAD dateiname <cr> |

                  STACKSIZE cardinal <cr> |
                  EXEC dateiname  argument  <cr> |
                  IF EXITCODE integer anweisung <cr> |
                    _

                  DEFOUT   pfad   <cr> |
                  IMPOUT   pfad   <cr> |
                  MODOUT   pfad   <cr> |
                  MAINOUTPUTPATH   pfad   <cr> |

                  COMPILE dateiname <cr> |
                  MAKE   dateiname   <cr> |
2.2  Bedienung: Shell                                                     2 - 33
________________________________________________________


                  LINKSTACKSIZE cardinal <cr> |
                  NO OPTIMIZE <cr> |
                     _
                  PART OPTIMIZE <cr> |
                       _
                  FULL OPTIMIZE <cr> |
                       _
                  DRIVER   '+' | '-'   dateiname <cr> |
                  DELETEDRIVERS <cr> |
                  LINK dateiname <cr> |

                  DEFAULTPATH pfad-liste <cr> |
                  DEFPATH pfad-liste <cr> |
                  IMPPATH pfad-liste <cr> |
                  MODPATH pfad-liste <cr> |
                  SOURCEPATH pfad-liste <cr>  .

pfad-liste  =     <cr> Leerzeichen  Leerzeichen  pfad   .
pfad        =     laufwerk       'ü'         name | '..'   'ü'   .
dateiname  =   pfad name
name       =   prefix   '.' suffix              (einfacher Dateiname ohne Pfad )
laufwerk   =   Buchstabe ':'
prefix      =   Bis zu acht Buchstaben oder Ziffern
suffix      =   Bis zu drei Buchstaben oder Ziffern
argument  =   Ein Wort (Text, der nicht durch Leerzeichen unterbrochen ist)
text        =   Beliebiger Text
cardinal    =   Positive, ganze Zahl (0 bis 2^32-1)
integer     =   Ganze Zahl (-32767 bis 32768)

Die Anweisungen sowie alle Teile von Datei- und Pfadnamen dürfen sowohl in
Groß- als auch Kleinbuchstaben geschrieben sein.

Um einen Batch sowohl für die Erstinitialisierung für die Shell als auch allge~
mein verwendbar zu machen, ist es teilweise notwendig, bestimmte Funktionen
darin  nur  beim  Start  der  Shell  durchzuführen.  Wird  die  Anweisung
IF SHELLSTART vor eine normale Anweisung gestellt, wird sie nur berück~
  _
sichtigt, wenn der Batch beim Starten der Shell automatisch ausgeführt wird.

Mit WAIT wird der dahinter stehende Text in einer Alert-Box angezeigt und
erst bei Bestätigung des OK-Knopfs wird der Batch weiter abgearbeitet.

Teilweise  ist  es  wünschenswert,  bestimmte  Disk-Verzeichnisse  als  aktuelle
Pfade einzustellen. Jedes Laufwerk kann dabei ein eigenes aktuelles Verzeichnis
haben, zusätzlich gibt es ein aktuelles Laufwerk; das aktuelle Laufwerk bestimmt
mit seinem aktuellem Verzeichnis (Dir) den aktuellen Pfad. SETDRIVE wählt
mit  einem  angefügten  Laufwerksbuchstaben  das  aktuelle  Laufwerk,  SETDIR
bestimmt, falls beim Pfadnamen  kein  Laufwerk  angegeben  ist,  das  aktuelle
Verzeichnis des aktuellen Laufwerks, sonst den Pfad des angegebenen Lauf~
werks - das aktuelle Laufwerk wird jedoch nicht gewechselt (so kann damit das
2.2  Bedienung: Shell                                                     2 - 34
________________________________________________________


Verzeichnis auf einem anderen Laufwerk bestimmt werden). SETPATH schließ~
lich setzt den aktuellen Pfad, also das aktuelle Laufwerk mitsamt dem Ver~
zeichnis.

War  das  zu  kompliziert?  Dann  andersrum:  Normalerweise  verwenden  Sie
SETPATH.  Damit  geben  Sie  Laufwerk  und  Verzeichnis  an,  die  dann  zum
aktuellen werden. Das hat die gleiche Funktion wie die Eingabe des aktuellen
Pfads in den Umgebungsinformationen.

Wollen Sie aber auch die Pfade der anderen Laufwerke festlegen, verwenden
Sie für jedes Laufwerk SETDIR. Das wäre beispielsweise nützlich, wenn Sie die
Disk-Fenster in der Shell mit Shift bzw. der Einstellung Erzeuge Fenster auf
aktuellem Pfad (s. Shell-Parameter) öffnen wollen - dann wird der mit SETDIR
für das Laufwerk bestimmte Pfad  geöffnet.  Ebenso  wird  beim  GEM-Datei-
Selektor  ab  TOS  1.4  beim  Anklicken  eines  Laufwerks  dessen  aktuelles
Verzeichnis angezeigt.

Die Einträge im Tools-Menü können mit TOOL bestimmt werden. Bis zu zehn
Tools können eingetragen werden. Die Menüeinträge werden nacheinander auf~
gefüllt. Die dort aufgeführten Programme können durch die Menüanwahl oder
eine  Funktionstaste  bequem  ausgeführt  werden.

Für die Dateinamen bei TOOL gilt: Wird ein Pfad angegeben, wird beim Start
des Programms der Pfad zum aktuellen Pfad, ansonsten bleibt der in der Shell
gerade aktuelle Pfad erhalten.

Um alle Tools-Einträge zu löschen, dient die Anweisung DELETETOOLS.

Die LOAD-Anweisung veranlaßt die Shell, das angegebene Modul in den Spei~
cher zu laden, so, als ob es auf das Resident-Symbol gezogen würde. Die
Module stehen dann zum direkten Aufruf oder auch zum Import  in  andere
Module  zur  Verfügung  und  müssen  nicht  wiederholt  von  Diskette  geladen
werden. Besonders  interessant  ist  die  Möglichkeit,  Editor  und  Compiler  zu
laden - der Aufruf ist anschließend ohne Wartezeit möglich. UNLOAD gibt ge~
ladene Module entsprechend wieder frei.

Mit EXEC kann ein Programm oder Modul gestartet werden. Wenn es endet,
wird hinter der EXEC-Anweisung in der Batch-Datei fortgefahren. Nach der
Rückkehr kann über IF EXITCODE der Rückgabewert des Progamms geprüft
                        _
werden.  Nur,  wenn  er  zutrifft,  wird  die  dahinter  stehende  Anweisung
ausgeführt.  Dies  kann  zum  Beispiel  Verwendung  finden,  um  auf  abnorme
Abbruchbedingungen  eines  Programms  zu  reagieren:  Jedes  Programm  kann
beim Terminieren einen Integer-Wert zurückgeben. Bei Megamax-Programmen
kann dies über die Prozedur TermProcess aus dem Modul PrgCtrl geschehen.
Jedes Programm das normal terminiert, liefert als Rückgabewert  (Exitcode)
Null. Nun könnten Sie ein Programm schreiben, das mit einem anderen Wert
2.2  Bedienung: Shell                                                     2 - 35
________________________________________________________


terminiert, um beispielsweise damit dem Aufrufer anzuzeigen, daß ein anderes
Programm gestartet werden soll. Nehmen wir an, das Programm heißt A und
wenn es den Wert Eins zurückgibt, soll B gestartet werden. Also ist ein Batch
zu schreiben, der die folgenden beiden Zeilen enthält:
      EXEC  A
      IF EXITCODE  1  B
        _
Wird dieser Batch gestartet, läßt er A ausführen. Terminiert A, wird B nur
gestartet, wenn der Exitcode von A Eins ist.

STACKSIZE erlaubt die Einstellung der Stackgröße, die gestarteten Programmen
zur  Verfügung  gestellt  wird.  Normalerweise  wird  die  Stack-Größe  in  den
Umgebungsinfomationen (s.o.) bestimmt, jedoch kann es notwendig sein, diesen
Wert vor dem Starten bestimmter Module mit dem EXEC-Befehl zu ändern.

Ein Modula-Programm kann  mit  COMPILE  und  einem  angefügten  Quelltext-
(Source-) Namen übersetzt werden. Tritt dabei ein Übersetzungsfehler auf,
wird eine entsprechende Meldung angezeigt. Der Fehler kann dann wahlweise
ignoriert werden, so daß der Batch bei der nächsten Anweisung fortfährt oder
der Editor gestartet wird (dann ist die Batch-Abarbeitung abgebrochen  und
muß bei Bedarf erneut gestartet werden).

Mit  DEFOUT,   IMPOUT,   MODOUT   und   MAINOUTPUTPATH   können   die
Ausgabepfade des Compilers abweichend von der Standard-Einstellung (siehe
Kapitel  2.4,  Compiler)  bestimmt  werden.  Allerdings  werden  sie  nicht
automatisch am Ende des Batch-Laufs wieder auf ihre alten Werten gestellt.
DEFOUT, IMPOUT und MODOUT  können  nicht  rückgängig  gemacht  werden,
höchstens   durch   Neudefinition   der   Suchlisten   (DEFPATH,   IMPPATH,
MODPATH). Dagegen kann MAINOUTPUTPATH  durch  eine  leere  Pfadangabe
wieder ungültig gemacht werden. Nach einem Compiler-Fehler mit Aufruf des
Editors (oder Abbruch des Batch-Laufs) wird diese Anweisung allerdings nicht
mehr ausgeführt - dann muß ggf. die Einstellung des Ausgabe-Pfads in den
Compiler-Optionen (Parameter/Compiler) rückgängig gemacht werden.

Der Make-Vorgang kann durch die Anweisung MAKE gestartet werden. Wird
kein  Name  einer  Make-Datei  (Endung  M2M,  mit  Hilfsprogramm  ModRef
erstellt) angegeben, wird die Default-Make-Datei der Umgebungsinformationen
verwendet, ansonsten die angegebene.  Bei  einem  Fehler  in  der  Make-Datei
oder beim darauf folgenden Übersetzungsvorgang wird so verfahren, wie schon
oben bei der COMPILE-Anweisung beschrieben.

Um ein Programm im Batch zu binden, ist LINK zu verwenden. Der dahinter
anzugebende Modulname darf eine Pfadangabe enthalten. Ist dies der Fall, wird
die zu erzeugende gelinkte Programmdatei auf dem angegebenen Pfad erzeugt,
ansonsten dort, woher das angegebene Modul stammt. Der Optimierungsgrad,
die Stack-Größe, die das gelinkte Programm verwenden soll sowie die einzu~
bindenden Treiber-Module werden normalerweise in der Dialogbox des Linkers
2.2  Bedienung: Shell                                                     2 - 36
________________________________________________________


(Parameter/Linker) bestimmt (dazu mehr in Kapitel 2.6 über den Linker). Diese
Eintragungen können aber optional auch vom Batch verändert werden (natürlich
müssen sie vor dem betreffenden Linker-Aufruf abgearbeitet werden!):

LINKSTACKSIZE bestimmt mit der angegebenen Zahl die Stackgröße für das
zu linkende Programm; sie sollte mindestens 2000 (Bytes) betragen. Mit einer
der Anweisungen NO OPTIMIZE, PART OPTIMIZE oder FULL OPTIMIZE wird
                      _                  _                      _
keine, verkürzte bzw. vollständige Optimierung des Programms erreicht. Nach
DRIVER  kann  ein  Treiber-  (Konfigurations-)  Modul  angegeben  werden.
Insgesamt  können  bis  zu  acht  solcher  Module  eingetragen  werden.  Dem
Modulnamen hinter  DRIVER  kann  ein  Plus-  oder  Minuszeichen  vorangestellt
werden  (ohne  Leerzeichen!),  je  nachdem  wird  es  als  selektiertes  oder
abgeschaltetes Modul eingetragen (nur selektierte Module werden beim Linken
als Treiber mit eingebunden) ist kein solches Zeichen vor dem Namen, wird
das Modul als selektiert übernommen. Ein bereits konfiguriertes Modul wird
nicht doppelt eingetragen, sondern die neue Definition überschreibt dann die
alte. Durch  die  Anweisung  DELETEDRIVERS  können  allerdings  alle  Treiber-
Eintragungen gelöscht werden.

Um die weiteren Einträge der Batch-Datei zu erklären, holen wir etwas weiter
aus - als Vorwarnung spendieren wir eine neue Überschrift:


Suchpfade und Pfadlisten

Zu guter Letzt können Sie in der Batch-Datei verschiedene Pfadlisten angeben -
also Listen von Directories, die beim Suchen verschiedener Dateitypen abge~
sucht werden sollen. Vier dieser Pfadlisten werden ausschließlich vom Modula-
System selbst (Compiler, Linker) benutzt:

DEFPATH       für übersetzte Definitionsmodule:
                 Hier sucht der Compiler die Definitionsdateien (Endung DEF)
                 der importierten Module.
                 Im ersten angegebenen Pfad legt der Compiler neu erzeugte
                 (übersetzte) Definitionsdateien ab.

IMPPATH       für übersetzte Implementationsmodule,
MODPATH      für übersetzte Haupt- (Programm-) Module:
                 Auf  diesen  beiden  Pfadlisten  sucht  der  Linker  (nicht  der
                 Loader!)  nach  einzubindenden  Modul-Codes,  die  vom  zu
                 linkenden Programm importiert werden.
                 Im ersten angegebenen Pfad legt der Compiler neu erzeugte
                 (übersetzte) Implementations- bzw. Haupt-Modul-Codes ab.

SOURCEPATH  für alle Quelltexte (Sourcen):
                 Hier suchen Compiler und Editor nach den Quelltexten, wenn
                 diese nicht auf dem angegebenen Pfad zu finden sind.
2.2  Bedienung: Shell                                                     2 - 37
________________________________________________________


Die Modula-Shell selbst (bzw. deren Loader) sucht alle Module, die ausgeführt
werden sollen, in der DEFAULTPATH-Liste. Das gilt auch für Module, die per
LOAD-Anweisung in der Batch-Datei geladen werden sollen. Eventuelle LOAD-
Anweisungen in der Batch-Datei, die beim Shell-Start automatisch ausgeführt
wird,  sollten  also  hinter  der  dort  -  notwendigerweise  -  aufgeführten
DEFAULTPATH-Definition stehen.

Außerdem steht die DEFAULTPATH-Liste Systemprogrammen, wie dem Make,
zur Verfügung: Die Variable StdPaths im Modul ShellMsg enthält eine kodierte
Form dieser Liste (vom Datentyp PathList). In der Dokumentation (Definitions~
modul) zum Modul Paths erfahren Sie, wie Sie durch einfachen Aufruf einer
Prozedur eine Datei in allen Verzeichnissen dieser (oder auch einer anderen)
Pfadliste suchen lassen können. Um auf einfache Weise anwenderfreundliche
Programme zu verwirklichen, ist die Benutzung dieser Suchfunktion vor dem
Zugriff  auf  Dateien  sehr  empfehlenswert.  Um  die  Pfadliste  für  gelinkte
Programme, also außerhalb der Shell, anzulegen, gibt es das Modul InitPathList
im UTILITY-Ordner.

Vorsicht!
      Es ist unbedingt darauf  zu  achten,  daß  nach  einer  Pfadlisten-
      Anweisung  die  in  den  folgenden  Zeilen  aufgeführten  Pfade  alle
      mindestens  um  ein  Leerzeichen  eingerückt  sind  und  keine
      Leerzeilen bis zum Ende der Liste vorkommen!

Die Syntax der Pfadnamen wird weiter unten erklärt für den Fall, daß Sie mit
ihr noch nicht vertraut sind.

Wird ein Pfadname mit einem Sternchen (und einem darauf folgenden Ordner-
Trennstrich,  also  "*ü")  angeführt,  wird  es  von  den  Systemprogrammen
(Compiler, Make, Shell usw.) durch den Pfad der Shell ersetzt (dieser steht im
Modul ShellMsg). Damit können die Pfade so angegeben werden, daß die Shell
zusammen mit ihren Unterverzeichnissen problemlos in jeden beliebigen Ordner
(einer ausreichend großen Harddisk) kopiert werden kann und erstmal keine
Korrekturen an den Pfadlisten vorgenommen zu werden brauchen, um mit dem
System arbeiten zu können. Dies wurde übrigens auch bei der Zusammen~
stellung des Megamax-Systems  auf  Ihren  erworbenen  Disketten  ausgenutzt
(siehe die Batch-Datei MM2SHELL.M2B).

Am  Ende  der  Pfadliste  kann  ein  Fragezeichen  als  Dateiname  eingetragen
werden.  Dies  bewirkt,  daß  die  GEM-Dateiauswahl-Funktion  (File-Selektor)
aufgerufen wird, wenn eine gesuchte Datei nicht auf den vorigen Pfaden der
Liste gefunden werden kann.
2.2  Bedienung: Shell                                                     2 - 38
________________________________________________________


Der Aufbau einer Pfadangabe ist zwar nicht Megamax-spezifisch,  soll  aber
doch noch kurz erläutert werden:

* Die Laufwerksangabe durch Laufwerksbuchstaben und Doppelpunkt ist optio~
nal; wenn sie fehlt, wird das gerade aktive Laufwerk benutzt.

* Der folgende Schrägstrich gibt an, daß vom Stamm-Inhaltsverzeichnis (auch
Wurzel- oder Root-Directory) des Laufwerks ausgegangen wird. Fehlt er, dann
beginnt der Pfad im gerade aktiven Verzeichnis, das sich der Atari zu jedem
Laufwerk einzeln merkt.

*  Beginnen  Sie  im  aktiven  Verzeichnis,  so  können  Sie  zunächst  ins
übergeordnete Verzeichnis heraufsteigen, indem Sie '..ü' folgen lassen.

* Nachdem nun der Ausgangspunkt des Pfades definiert ist, können Sie sich
von dort beliebig tief in Ordner (Subdirectories) 'hineinwühlen'. Die Ordnerna~
men werden in der Reihenfolge angegeben, in der Sie immer tiefer in sie 'hin~
eintauchen'. Zur Trennung der Namen dient wieder der Schrägstrich.

* Am Ende eines Pfadnamens sollte immer ein Schrägstrich stehen (ggf. fügt
die Shell beim Einlesen des Pfades selbst einen an).

Um die Verwirrung etwas zu lindern, hier ein Beispiel. Betrachten wir folgende
Directory-Struktur:

      Disk A:             <Wurzel>
                             5 8
                  MODULA      ZAEH
                     5 8
              SHELL     LIBRARY
                           5 8
                       IMP      DEF

Angenommen, Sie wollen einen Pfad ins 'DEF'-Verzeichnis konstruieren (etwa
für die DEFPATH-Liste in der Batch-Datei). Die ausführlichste Angabe wäre
"A:üMODULAüLIBRARYüDEFü".  Das  funktioniert  natürlich  nur,  solange  die
Diskette in Laufwerk A bleibt... Aber  Sie  wissen  ja,  daß  gerade  die  Shell
gestartet worden ist - also wird sicher das richtige Laufwerk gerade aktiv
sein. Daher genügt die Angabe "üMODULAüLIBRARYüDEFü".

Beide  oben  genannten  Pfade  beginnen  im  Wurzelverzeichnis.  Wenn  der
MODULA-Ordner in einen anderen Ordner hineinkopiert wird (oder wenn Sie
LIBRARY und SHELL  direkt  ins  Wurzelverzeichnis  legen),  schicken  Sie  den
Rechner auf den Holzweg. Noch flexibler ist es daher, den Pfad relativ zum
aktiven  Verzeichnis  (SHELL,  nehmen  wir  an)  anzugeben!  ..üLIBRARYüDEFü
tut's,  solange  der  LIBRARY-Ordner  neben  dem  SHELL-Ordner  in  einem
übergeordneten Verzeichnis steht.
2.2  Bedienung: Shell                                                     2 - 39
________________________________________________________


Umgang mit mehreren Projekten

Unter einem Projekt bei Megamax Modula-2 verstehen wir die Arbeit an einem
Programmpaket, das mehrere Module umfaßt und das seine eigene, individuelle
Umgebung hat.

Ein Beispiel: Nehmen wir an, Sie arbeiten abwechselnd an zwei Programmen,
das eine sei ein kleines Terminal-Programm (zur Daten-Kommunikation über
Telefon), das andere ein Grafikprogramm zur Darstellung von physikalischen
Vorgängen. Nun bietet es sich an, die jeweils projekt-spezifischen Dateien in
getrennten Ordner zu sammeln. Denken wir uns, Sie hätten zwei Ordner auf
Ihrer  Harddisk  (ja,  sowas  braucht  man  heutzutage),  je  einen  für  jedes
Programmpaket,  in  denen  die  jeweiligen  Quelltext-Dateien  abgelegt  werden
sollen.

Da die beiden Programme vielleicht auch verschiedene Optionen (Stack-Größe,
Treiber-Module usw.) benötigen, sollten Sie sich dafür je eine Projekt-Datei
anlegen. Diese Projekt-Dateien sind praktisch die Parameter-Dateien mit den
Endungen M2P.  Wenn  Sie  alles  richtig  installiert  haben,  können  Sie  durch
einfache Aktionen zwischen Ihren beiden Projekten hin- und herwechseln und
finden bei beiden die individuellen Einstellungen und Arbeitsdateien vor.

Kommen wir also zum Erstellen einer Projekt-Datei. Zuerst erstellen Sie eine
Batch-Datei, die die gewünschten Suchpfade enthält. Nehmen Sie am besten
Ihre Standard-Batch-Datei MM2SHELL.M2B und verändern Sie die Pfadlisten
darin, so daß die zusätzlichen Ordner für das jeweilige Projekt berücksichtigt
werden. Am besten ist es, diese Pfade immer als erstes in die Listen  zu
schreiben,  damit  sie  Vorrang  vor  den  restlichen  haben.  Speichern  Sie  die
Batch-Datei dann unter einem anderen Namen wieder ab.

Daraufhin  tragen  Sie  den  Namen  hinter  der  Batch-Datei  in  den  Shell-
Parametern ein. Dann vergeben Sie auch einen neuen Namen für die dortige
Parameter-Datei. Nun können Sie Ihr Disk-Verzeichnis des  Projekt-Ordners
öffnen, die verwendeten Quelltexte als Arbeitsdateien eintragen und sonstige
Parameter einstellen, beispielsweise die  Stack-Größe  oder,  wenn  das  feste
Linken  des  Programms  öfter  benötigt  wird,  auch  die  Linker-Optionen
(verwendete Konfigurationsmodule usw.).

Sehr nützlich ist auch das Erzeugen einer Make-Datei zum Hauptmodul des
Projekts  (siehe  Kapitel  2.7  zum  Erstellen  einer  Make-Datei),  die  dann  als
Default-Make in den Umgebungsinformationen eingetragen wird.

Sind alle Einstellungen vorgenommen, kann durch Drücken von Control-X, der
Anwahl des Menüpunkts Parameter sichern oder einfach durch Verlassen der
Shell mit Parameter-Sicherung  die  vorher  als  Parameter-Datei  eingegebene
Projekt-Datei  gespeichert  werden.  Wenn  Sie  dann  die  Shell  neu  aufrufen,
2.2  Bedienung: Shell                                                     2 - 40
________________________________________________________


wird  erstmal  wieder  die  Standard-Einstellung  aus  der  Parameter-Datei
MM2SHELL.M2P  vorgenommen.  Sie  können  nun  aber  jederzeit  die  neu
angelegte Projekt-Datei ausführen, um deren Einstellungen wieder hervorzu~
holen, z.B. indem Sie die Projekt-Datei im Disk-Inhaltsverzeichnis suchen und
durch Doppelklick oder durch Ziehen auf das Ausführen-Symbol aktivieren. Ein
anderer,  sehr  bequemer  Weg  ist,  die  oft  verwendeten  Projekt-Dateien  als
Tools in der Standard-Batch-Datei einzutragen.

Sie können sogar schon beim Start der Shell dafür sorgen, daß statt  der
Standard-Parameter-Datei MM2SHELL.M2P eine andere verwendet wird: Dazu
müssen Sie die Shell unter dem GEM-Desktop für Dateien der Endung M2P
anmelden. Dann genügt ein Doppelklick auf die Projekt-Datei, um die Shell zu
starten und das Projekt sofort vor sich  zu  haben.  Um  dies  zu  erreichen,
klicken  Sie  im  GEM-Desktop  die  Shell  MM2SHELL.PRG  einfach  (also  nicht
starten!) an. Dann wählen Sie in der Menüzeile Extras/Anwendung anmelden.
Dort  geben  Sie  dann  als  geforderte  Endung  "M2P"  ein  und  klicken  auf
installieren. Zuletzt wählen Sie Arbeit sichern an. Daraufhin können Sie nun
auf jede M2P-Datei doppelt klicken, um die Shell damit zu starten. (Bei älteren
TOS-Versionen müssen Sie aber darauf achten, daß sich die Projekt-Dateien
im  Verzeichnis  der  Shell  befinden,  da  diese  sonst  nicht  gefunden  wird.
Probieren Sie dies ggf. aus.)
2.2  Bedienung: Shell                                                     2 - 41
________________________________________________________


Fehlermeldungen der Shell

Beim Programmieren kann erfahrungsgemäß einiges schiefgehen. Im Megamax
Modula-System gibt es vier Kategorien von Fehlermeldungen, die  in  solchen
Fällen erscheinen können.

* Ladefehler können auftreten, wenn ein Modul ausgeführt werden soll und nicht
alle benötigten Module zur Verfügung stehen. Die  Fehlermeldungen  beginnen
mit '<Modulname> konnte nicht ausgeführt werden', gefolgt von einer Beschreibung
des Problems. Diese Meldungen werden vom  Loader  erzeugt;  Erläuterungen
finden Sie im Kapitel 5.

* Laufzeitfehler treten bei der Ausführung fehlerhafter Anwenderprogramme
auf. Die Fehlerbeschreibung, der Modul- und der Prozedurname werden ange~
zeigt. Sie können sich entscheiden zwischen

    Back/Forward:
    erlauben die Suche nach der Fehlerposition im Text (siehe 2.5);
    Exit
    verläßt die Fehlersuche und bietet drei weitere Möglichkeiten:

    Cont
    setzt das Programm fort. Bei manchen fatalen Fehlern ist eine sinnvolle
    Fortsetzung nicht möglich, und diese Option wird nicht angeboten.
    Quit
    bricht das Programm ab und kehrt zurück zur Shell.
    Edit
    läßt die durch Forward/Back bestimmte Fehlerstelle suchen und im Editor
    anzeigen, sofern der Quelltext des Moduls vorhanden ist. (siehe 2.5)

Eine kommentierte Liste der Fehlermeldungen steht im Anhang A.2.

*  Übersetzungsfehler  entstehen  natürlich  beim  Compilieren.  Eine  Liste  der
Fehlermeldungen  enthält  der  Anhang  A.1;  wie  Sie  auf  Übersetzungsfehler
reagieren können, beschreibt Kapitel 2.4.

* Bedienungsfehler in der Shell. So kommen Meldungen, wenn Sie mehr als
sieben  Fenster  öffnen,  mehr  als  zehn  Arbeitsdateien  anfordern,  mehr
Programme laden wollen, als freier Speicher zur Verfügung steht, usw. Die
Meldungen sind alle selbsterklärend.
2.2  Bedienung: Shell                                                     2 - 42
________________________________________________________





















                               Diese Seite wurde blank geputzt.
2.3  Bedienung: Editor                                                    2 - 43
________________________________________________________


2.3   Editor


Einführung

Als Teil des Megamax Modula-Systems haben Sie auch einen eigenen Editor
erhalten (genau genommen sogar zwei!). Er dient zur Eingabe (und Korrektur)
der  Programmtexte.  Die  Texte  werden  als  Standard-ASCII-Dateien  (direkt
lesbare Textdateien) abgelegt und dem Compiler übergeben.

Der Editor ist speziell zum Schreiben von Programmtexten konzipiert worden.
Ihre  Briefe  werden  Sie  vielleicht  auch  weiterhin  mit  einer  speziellen
Textverarbeitung  schreiben  wollen;  zum  Programmieren  bietet  Ihnen  der
Megamax-  Editor  aber  eine  Reihe  nützlicher  Sonderfunktionen  bei  über~
sichtlicher Bedienung.


Wahl des Editors

Prinzipiell können Sie jeden Editor verwenden, der normale Textdateien erzeugt
- die optimale Zusammenarbeit mit Shell und Compiler des Modula-Systems
erlauben allerdings nur die beiden mitgelieferten Editoren. (Die Zusammenarbeit
der Programme wird durch die Shell organisiert. Da Sie diese im Quelltext
erhalten, können Sie auch eine Anpassung für Ihren Lieblingseditor vornehmen,
wenn Sie sich nicht umstellen möchten - die wichtigste Änderung dürfte die
Übergabe der Fehlerposition und -meldung betreffen.)

Unser Standard-Editor heißt GME. Unter anderem erlaubt er, mehrere Texte
im  Speicher  zu  bearbeiten,  bietet  jedoch  bisher  noch  keine  echten  GEM-
Fenster,  statt  dessen  werden  die  Texte  auf  Befehl  abwechselnd  auf  dem
Bildschirm angezeigt. Die Bedienung ist dem Konzept des legendären Editors
Word-Star nachempfunden. Der GME ist einfach zu bedienen, vor allem wegen
seiner GEM-Menüleiste, deswegen empfehlen wir den Programmier-Einsteigern
diesen Editor zur Benutzung.

Alternativ bieten wir einen kompakteren und schnelleren Editor, der allerdings
mehr Eingewöhnung verlangt: Der Gepard-Editor (GEP ED). Auch er arbeitet
                                                         _
optimal  mit  dem  Entwicklungssystem  zusammen.  Er  ist,  wie  der  GME,  in
Modula geschrieben, hat jedoch einige deutliche  Optimerungen  in  Assembler
erfahren. Er belegt nur ca. 50KByte (GME: 150) des Speichers in der Shell
und ist deshalb bei knappem Speicher dem GME vorzuziehen.
2.3  Bedienung: Editor                                                    2 - 44
________________________________________________________


Der GME wurde aus einem Universaleditor  entwickelt,  der  auch  zur  Text~
verarbeitung geeignet war. Demgegenüber ist der Gepard-Editor speziell auf
das Programmentwickeln zugeschnitten und bietet keine GEM-Oberfläche - für
die  Veteranen:  Sein  Konzept  ist  dem  des  UCSD-Programmeditors  nach~
empfunden, nur ist er wesentlich schneller. Der Editor ist gewöhnungsbedürftig,
aber  unglaublich  effektiv  für  Vielprogrammierer  -  wir  Megamax-Entwickler
verwenden ihn alle!

Beide Editoren erlauben es, den Programmtext im  Speicher  zu  übersetzen,
ohne daß der Text abgespeichert und der Editor verlassen zu werden braucht.
Dies verkürzt die Turn-Around-Zeit (Zeit zwischen Editieren, Übersetzen und
Starten) deutlich.

Auch Tempus (von CCD) läßt sich sehr bequem als Editor verwenden. Einzig
die Fehleranzeige vom Compiler beherrscht er nicht - die Shell sieht aber eine
Option vor, so daß Compilerfehler  vor  dem  Editor-Start  angezeigt  werden.
Nach einer Bestätigung mit der Return-Taste wird der Editor gestartet und er
zeigt dann die Fehlerposition im geladenen Text an.

Bei Tempus können Sie ein Programm zwar nicht im Speicher direkt überset~
zen lassen, aber der Komfort kommt auch hier nicht zu kurz: Drücken Sie
Control-1 (Sie müssen die Eins vom rechten Ziffernblock verwenden!), wird der
Text automatisch gespeichert, Tempus verlassen und automatisch der Compiler
gestartet, der dann den Programmtext übersetzt, den Sie von der Shell an den
Editor beim Aufruf übergeben hatten (und das ist in der Regel auch der, den
Sie dann mit Control-1 zum Übersetzen abspeichern lassen). Control-2 teilt
der Shell mit, daß sie nach erfolgreicher Übersetzung dieses Modul starten
soll,  Control-3  bewirkt  nicht  das  Übersetzen  des  geladenen  Programms,
sondern aktiviert das Default-Make, das in der Shell auch über die Taste M
auslösbar ist. Schließlich läßt Control-4 nach dem - erfolgreichen - Make-Lauf
das Programm wiederum gleich starten.

Leider lassen sich die Versionen 2.00 bis 2.04 von Tempus nicht resident in
der Shell laden: Beim wiederholten Start in der Shell würde er nicht mehr
funktionieren. Wenden Sie sich in diesem Falle ggf. an CCD, um eine neuere,
korrigierte Version zu erhalten. Alle anderen Versionen lassen sich resident
laden, aber benötigen sehr (wirklich sehr) viel mehr Speicher als die Programm~
datei lang ist. Auch hier sollten Sie sich nicht verwirren lassen - das muß so
sein!
2.3  Bedienung: Editor                                                    2 - 45
________________________________________________________


Vorbereitungen und Parameter für den Editor

Bevor der Editor Ihres Ver~
trauens von der Shell richtig
aufgerufen   werden   kann,
muß    zumindest    dessen
Dateiname bekannt  gemacht
werden.      Unter      dem
Menüpunkt Parameter/Editor
sind  alle  Optionen  für  den
Editor erreichbar. Hier kann
hinter Editor:  dessen  Name
eingetragen werden. Soll der
GME verwendet werden, kann dieser Name, wie im Bild zu sehen, verwendet
werden. Für den  Gepard-Editor  ist  GEP ED  einzutragen,  bei  allen  anderen
                                            _
Editoren ist ihr vollständiger Dateiname inclusive seiner Endung zu verwenden
(Tempus: TEMPUS.PRG). Bei Editoren, die andere Dateien nachladen müssen,
wie eine RSC-Datei oder Konfigurationen, muß außerdem deren Pfadname mit
angegeben werden. Haben Sie beispielsweise einen Editor namens EDIT.PRG,
der im Ordner C:üTEXTE mitsamt seiner Resource-Datei EDIT.RSC steht, ist
C:üTEXTEüEDIT.PRG einzutragen.

Die mitgelieferten Editoren können, da sie mit dem Megamax-Modula-System
erstellt  wurden,  auf  die  Pfadlisten  in  ShellMsg  zugreifen,  speziell  auf  die
Suchpfade für die Quelltexte (über SourcePath in Batch zu bestimmen). So
brauchen  Sie  beim  Laden  eines  Textes  diesen  nicht  erst  in  den  vielen
Verzeichnissen zu suchen, statt dessen sucht der Editor die Datei selbständig
auf den Source-Pfaden. Wird ein anderer Editor verwendet, kann die Shell das
übernehmen, wenn sie beim Editor-Aufruf den Dateinamen übergibt. Dazu muß
nur die Option Shell durchsucht Source-Pfade für den Editor aktiviert sein.
Dann reicht es beispielsweise, in der Shell mit Control-P den Namen eines
Textes ohne dessen Pfad einzutippen und dann den Editor mit Control-E zu
starten.

Wenn Editoren es nicht vermögen, eine Fehlermeldung beim Aufruf übergeben
zu bekommen, um sie dann anzuzeigen, muß die Shell dies erledigen. Dazu
dient der Schalter Shell zeigt Compiler-Fehler vor Editor-Aufruf an.  Ist  er
eingeschaltet, zeigt die Shell nach einem Compiler-Fehler diesen an, und erst
nach Drücken der Return-Taste wird der Editor gestartet. Verträgt der Editor
die  Fehlermeldung  nicht  (z.B.  TEMPUS),  muß  außerdem  weiter  unten  bei
Argumentzeile der Schalter Fehlermeldung deaktiviert sein.

Die Temporären Dateien dienen zur Übergabe von Informationen an den Editor
und zurück an die Shell. Der einzige uns bekannte Editor, der diese Art der
Parameterübergabe unterstützt ist der Emacs-Editor. Der ist programmierbar,
und so hat ein Megamax-Anwender ein Programm erstellt, das es erlaubt, von
der  Shell  Textname,  Fehlermeldung  und  -position  anzunehmen  und  beim
2.3  Bedienung: Editor                                                    2 - 46
________________________________________________________


Verlassen die Shell wiederum zum Compiler-Start zu veranlassen, wie dies
auch bei den von den beiden Megamax-Editoren möglich ist. Sind Sie an dieser
EMACS-Einbindung interessiert, wenden Sie sich an Application Systems.

In  der  Argumentzeile  an  den  Editor  können  Textname,  Fehlermeldung  und
-position  vom  Compiler  bzw.  von  der  Shell  beim  Aufruf  an  den  Editor
übergeben werden. Die Megamax-Editoren erlauben alle Übergaben. TEMPUS
beispielsweise  erlaubt  die  Angabe  der  Cursorposition,  jedoch  nicht  die  der
Meldung, sodaß diese dann zu deaktivieren wäre.

Wollen Sie einen Editor verwenden, der noch andere  Bedingungen  an  seine
Benutzung stellt, z.B. daß bei der Fehlerposition die Werte für Spalte und Zeile
zu vertauschen wären, können Sie dies selbst an der Shell-Source vornehmen:
Der Editor-Aufruf wird in der Funktion hdedit vorbereitet. Die Fehlermeldung
vom Compiler wird bei einem der Aufrufe von hdedit aufbereitet. Nach der
Anpassung muß die Shell neu übersetzt und dann gelinkt werden. Zum Linken
bietet  sich  der  Batch  LINKSHEL.M2B  an,  der  dazu  alle  erforderlichen
Parameter einstellt.


Aufruf des Editors

Den Editor können Sie auf drei Wegen starten:

    * Aus der Shell: Klicken Sie das Editor-Symbol auf der Ar~
    beitsfläche an (Editieren der Arbeitsdatei)  oder  legen  Sie
    einen Dateinamen auf dem Editor-Symbol ab. Wollen Sie ein
    neues Dokument beginnen, so geben Sie zunächst einen leeren Namen an.

    * Nach Übersetzungsfehlern: Je nach Wahl der Editor-Optionen ruft die
    Shell den Editor sofort auf oder bietet Ihnen erst den Aufruf des Editors
    an. Wenn Sie dann diese Option wählen, wird automatisch der fehlerhafte
    Text geladen, der Cursor wird an der Fehlerstelle positioniert, und in der
    Kopfzeile des Editors erscheint eine Fehlerbeschreibung.

    * Nach Laufzeit-Fehlern: Wenn Ihnen der Text des fehler~
    haften Programms zur Verfügung steht, können Sie  nach
    Laufzeitfehlern die Scanner-Funktion wählen. Der Compiler
    ermittelt die Textposition,  an  der  der  Fehler  auftrat,  und  zeigt  Ihnen,
    genau wie bei Übersetzungsfehlern, die Fehlerstelle mit Beschreibung im
    Editor.


Bedienung des Editors

Die Bedienung der beiden Editoren wird in separaten Anleitungen beschrieben,
die Sie im Anhang finden.
2.4  Bedienung: Compiler                                                 2 - 47
________________________________________________________


2.4    Compiler

Hier erläutern wir die eigentliche Handhabung des Modula-Compilers. Wenn Sie
sich über den übersetzten Sprachumfang oder die Compiler-Optionen in Quell~
texten informieren wollen, lesen Sie bitte Kapitel 3 dieses Handbuchs.


Aufruf des Compilers

Der Compiler wird aus der Shell gestartet, indem Sie
* eine Textdatei aus einem Disk-Fenster mit der Maus greifen
  und auf das Compiler-Symbol schieben;
* das Compiler-Symbol doppelt anklicken, um die Arbeitsdatei zu übersetzen;
* die Taste C drücken, um die Arbeitsdatei zu übersetzen (o. Ctrl-C für die
  aktuelle Datei).

Der Pfad der Quelldatei muß nicht angegeben werden - der Compiler sucht die
Datei automatisch auf den Source-Pfaden (SourcePath in der Batch-Datei).

Falls die angegebene Textdatei vom Compiler nicht gelesen werden kann, fragt
der Compiler Sie nochmals nach einem Datei-Namen. Durch eine Leereingabe
können Sie den Compiler dann auch wieder verlassen. Wenn der Text gefunden
wird, beginnt der Compiler die Übersetzung.

Die  Endungen  (Suffix,  Extension)  der  Quelldatei-Namen  sind  beliebig.  Bei
Megamax Modula verwenden wir in der Regel
  .M  für Haupt-Modul-Quellen (Bsp: MSHELL.M, TEXTDEMO.M),
  .I   für Implementationsmodul-Quellen (Bsp: DEBUG.I, MOSCONFI.I),
  .D  für Definitionsmodul-Quellen (Bsp: INOUT.D, DEBUG.D).

Benötigte Definitionsmodule  werden  automatisch  gesucht.  Als  Name  werden
dabei die ersten 8 Zeichen des Modulnamens (also nicht des Dateinamens!),
gefolgt von der Extension .DEF, angenommen. Diese Dateien werden auf allen
Pfaden  gesucht,  die  Sie  in  der  Batch-Datei  als  DefPath  angegeben  haben
(siehe Kapitel 2.2 - Shell).
2.4  Bedienung: Compiler                                                 2 - 48
________________________________________________________


Die erzeugten Dateien

Den  Namen  der  erzeugten  Code-Datei  bestimmt  der  Compiler  ebenfalls
automatisch. Wieder werden die ersten 8 Zeichen des Modulnamens verwendet;
die Extension lautet

  .MOD  für Programm-Modul-Codes,
  .DEF   für Definitions-Codes und
  .IMP   für Implementations-Codes.

Andere  Endungen  können  Sie  über  die  Compileroption  $E  einstellen  (siehe
Kapitel 3.3, Compileroptionen), z.B. MOS oder MTP (äquivalent zu TOS und
TTP bei gelinkten Programmen, während MOD wie PRG behandelt wird).

Die Standard-Endungen können Sie aber auch verändern - näheres dazu in
Kapitel 5.

Der  Ausgabepfad  für  das  übersetzte  Modul  wird  normalerweise  über  die
Suchpfade bestimmt, die in der Batch-Datei stehen, welche beim Start der
Shell ausgeführt wird: Der Compiler wählt jeweils den ersten Pfad aus der
Pfadliste für Definitions-, Implementations- oder Programm-Module. Über die
Batch-Anweisungen  DEFOUT,  IMPOUT  und  MODOUT  können  aber  auch
individuelle  Ausgabepfade  eingestellt  werden  -  sind  dahinter  keine  Pfade
angegeben, wird die Code-Datei in das Verzeichnis geschrieben, aus dem die
jeweilige Quell-Datei stammt.

Ist allerdings ein Pfad über die Batch-Anweisung MainOutputPath oder über die
Compiler-Parameter  in  der  Shell  (siehe  folgenden  Abschnitt  Compiler-
Parameter)  eingegeben,  hat  dieser  Vorrang  vor  allen   anderen   Pfad-
Bestimmungen!


Übersetzungsfehler

Findet der Compiler in dem übersetzten Programmtext einen Fehler, bricht er
den Übersetzungsvorgang ab und meldet dies der Shell, die dann entweder den
Editor  sofort  aufruft  oder  erst  ein  Fenster  öffnet,  in  dem  sie  Ihnen  die
Fehlermeldung  präsentiert  und  Sie  vor  die  Wahl  stellt,  die  Fehlerstelle  im
Editor zu korrigieren oder die Übersetzung ganz abzubrechen.

Um als Fehlermeldung eine Beschreibung des Problems ausgeben zu können,
benötigt der Compiler die Fehlerdatei. Sie heißt normalerweise 'MODULA.ERR'
Fehlt diese Datei, dann wird nur eine Fehlernummer angezeigt, deren Bedeu~
tung Sie im Anhang A.1 des Handbuchs nachschlagen können. Dort finden Sie
zu vielen Fehlermeldungen auch zusätzliche Hinweise, die bei der Behebung des
Fehlers helfen können.
2.4  Bedienung: Compiler                                                 2 - 49
________________________________________________________


Compiler-Parameter

Über die Anwahl Parameter/
Compiler im Menü der Shell
können Sie die globalen Op~
tionen  des  Compilers  ein~
stellen.

Ist  Ausgabe  der  Kurzmel~
dungen  mit  einem  Häkchen
versehen, werden die Namen
der importierten Module, der
übersetzten Prozeduren und
die  Anzahl  der  übersetzten
Zeilen ausgegeben. Die gleiche Funktion kann  in  Programmtexten  durch  die
Compileroption $Q gesteuert werden (siehe 3.3, Compilerdirektiven; dort finden
Sie auch Tips zur Anwendung dieser Option).

Ausgabepfad:  Soll  ein  übersetztes  Modul  nicht  auf  dem  Pfad  gespeichert
werden,  der  in  der  Start-Batch-Datei  für  die  entsprechende  Modulart
angegeben ist, kann hier ein anderer Pfad eingetragen werden, der dann auf
alle erzeugten Modularten wirkt. Dieser Pfad kann auch mit dem Batch-Befehl
MAINOUTPUTPATH bestimmt werden. Siehe auch Kapitel 2.2 zu den Batch-
Anweisungen.

Die Direktiven erlauben die Beeinflussung des Verhaltens des Compilers beim
Übersetzen. Beispielsweise können Sie bestimmen, ob zusätzlicher Code für
Laufzeitprüfungen erzeugt werden soll. Näheres zur Funktion den Direktiven in
Kapitel 3.4. Statt die Direktiven in den Quelltext einzufügen, können sie hier in
der Eingabezeile voreingestellt werden. Jeder Direktiven-Buchstabe muß dabei
mit  einem  Plus-  bzw.  Minuszeichen  eingeleitet  werden,  mehrere  Direktiven
werden  durch  Leerzeichen  getrennt.  Im  Bild  sehen  Sie  beispielsweise  die
Direktiven $Z+ und $R-.

In der Library MM2DEF.M2L sind (fast) alle übersetzten Definitionsdateien der
Megamax-Bibliotheken  zusammengefaßt.  Dies  spart  Platz  auf  der  Disk  und
beschleunigt den Übersetzungsvorgang. Normalerweise sollte deshalb der Name
der  Datei  (mit  Pfad)  unter  Bibliothek  eingetragen  sein.  Ist  eine  Bibliothek
angegeben, haben die darin enthaltenen DEF-Dateien immer Vorrang vor den
separaten Definitions-Modulen in den Ordnern, die in der Pfadliste DefPath im
Batch angegeben werden können! Unter Umständen kann dies nicht erwünscht
sein - dann braucht einfach nur der Bibliotheksname gelöscht zu werden. Zur
Kontrolle, woher ein Definitionsmodul beim Übersetzen geladen wird, kann die
Anzeige der Kurzinformationen aktiviert werden.

Die Textdatei mit den Fehlermeldungen für den Compiler wird in Fehlerdatei
eingetragen, ggf. mitsamt dem Pfad.
2.4  Bedienung: Compiler                                                 2 - 50
________________________________________________________


Protokoll: Auf Wunsch erzeugt der Compiler  ein  Übersetzungsprotokoll.  Die
Ausgabebreite  (Anzahl  Spalten)  und  der  Name  der  Protokolldatei  (mit
Pfadangabe) können eingestellt werden. Der Inhalt der Protokolldatei wird in
einem speziellen Abschnitt auf einer der folgenden Seiten beschrieben.


Definitions-Codes: Bibliothek und Komprimierung

Die  übersetzten  Definitionsmodule  werden  vom  Compiler  praktisch  immer
benötigt,  darüber  hinaus  stören  sie  nur,  weil  sie  sonst  in  keiner  Weise
Verwendung finden.

Deshalb haben wir es ermöglicht, daß die Definitions-Codes alle in einer Datei
zusammengefaßt werden können. Damit ist das Weiterkopieren einfacher, es
werden nicht unzählige Verzeichnis-Einträge auf der Disk verschwendet, und
der Compiler kann sogar schneller darauf zugreifen.

Diese Datei, in der die Definitions-Codes zusammengefaßt sind, nennen  wir
Bibliotheks-Datei oder auch Library (das ist engl. und heißt in etwa das selbe).
Das Lesen der einzelnen Definitionen aus der Library ist für den Compiler sehr
einfach.  Demgegenüber  ist  es  aber  aufwendig,  ständig  neue  Dateien  darin
einzufügen  oder  auszutauschen.  Darum  bietet  es  sich  an,  nur  solche
Definitionen in die Library einzufügen, die keines ständigen Erneuerns bedürfen.
Die trifft vor allem auf die beim Megamax-System mitgelieferten MOS-Module
zu - die ändern höchstens wir, und das können wir dann gerade noch selbst
bewältigen.  Sie  selbst  können  also  auch  Definitions-Codes  hinzufügen,  nur
sollten Sie sich dieses Aspekts bewußt sein - wird die Definition verändert,
muß sie in der verwendeten Library aktualisiert werden, denn der Compiler
kann neu übersetzte Definitionen nicht automatisch in der Library ablegen, und
die Library hat immer  Vorrang  vor  den  Definitions-Codes  in  den  normalen
Verzeichnissen.

Die Definitions-Codes in die Library-Datei einzufügen, hat also zwei Vorteile:
Erstens sind sie darin hübsch  und  unauffällig  verpackt,  zweitens  kann  der
Compiler schneller darauf zugreifen, als dies bei den Einzeldateien möglich ist.
Natürlich müssen Sie nicht alle Ihre Definitions-Codes in die Library quetschen,
denn der Compiler kann  sie  selbstverständlich  auch  finden,  wenn  sie  ganz
normal  einzeln  in  den  Verzeichnissen  vorliegen:  Der  Compiler  sucht  beim
Importieren  zuerst  in  der  Library,  dann  in  der  DefPaths-Liste,  welche  im
Batch (meist MM2SHELL.M2B) bestimmt werden kann.

Mit dem Utility-Programm LibManager (ggf. erst übersetzen!) können Sie die
Library  bearbeiten.  Sie  können  sich  deren  Inhalt  ansehen  sowie  Dateien
einfügen, herauskopieren oder löschen. Das Programm  ist  menügeführt  und
daher (hoffentlich) selbsterklärend.
2.4  Bedienung: Compiler                                                 2 - 51
________________________________________________________


Eine weitere Optimierung besteht darin, die Definitionen zu komprimieren. Die
Codes in der mitgelieferten Library  MM2DEF.M2L  sind  bereits  komprimiert.
Dadurch ergibt sich eine Platzersparnis von ca. 55%. Der Compiler erkennt
beim Importieren automatisch, ob die Definitions-Codes komprimiert sind, und
expandiert sie dann selbstständig.

Jeder Definitions-Code kann komprimiert werden - der Compiler macht keinen
Unterschied, ob die Datei in der Library oder als Einzeldatei vorliegt.

Allerdings  hat  die  Kodierung  auch  einen  Nachteil:  Durch  das  notwendige
Expandieren dauert die Bearbeitung solcher Importe länger. Sind Sie stolzer
Besitzer  einer  Hard-Disk,  sollten  Sie  daher  die  Dateien  der  Library  alle
dekomprimieren, damit der Compiler damit keine unnötige Zeit mehr verbringen
muß.


Dekomprimieren der Dateien in der Library

Mit den Programmen Encode und Decode (UTILITY-Ordner) können die Dateien
(eigentlich jede beliebige Datei) gepackt und wieder entpackt  werden.  Beide
Programme sind sehr einfach anzuwenden: Beim Start wird nach einer Datei~
angabe gefragt. Geben Sie dann entweder die einzelne Datei  an  oder  ver~
wenden Sie Wildcards (z.B. D:üMM2üDEFü*.*), um mehrere Dateien in einem
Verzeichnis auf einmal anzusprechen. Wundern Sie sich nicht, daß das Kompri~
mieren relativ lange dauert - wir haben bisher  nur  die  Dekomprimierungs-
Algorithmen zeitlich optimiert, weil dies erstmal am wichtigsten war.

Wollen Sie nun die gepackte Library MM2DEF.M2L dekomprimieren, können Sie
nicht einfach die ganze Datei auf einmal entpacken. Statt dessen müssen Sie
erst mit dem LibManager alle Dateien herauskopieren, dann diese Einzeldateien
alle mit Decode dekomprimieren und am Ende alle Dateien wieder zu einer
neuen Library zusammenfügen (wiederum durch Verwendung von LibManager).


Protokoll

Ein Übersetzungsprotokoll kann bei der Suche nach Laufzeitfehlern oder auch
beim Verstehen eines fremden Programms nützlich sein, da es  neben  dem
Quelltext noch zusätzliche Angaben enthält.

Ein typisches Compilerprotokoll sieht z. B. so aus:

Megamax Modula Compiler 3.4h                            02-Nov-87   18:59

       1     0    D            MODULE Beispiel;
       2    0    D
2.4  Bedienung: Compiler                                                 2 - 52
________________________________________________________


       3    0    D            VAR     a: CARDINAL;
       4    0    D                      l: LONGCARD;
       5    0    D
       6    0    D            PROCEDURE square (c: CARDINAL): LONGCARD;
       7     1     D              BEGIN
       8    1     $00146           RETURN LONG (c) * LONG (c)
       9    1     $0015A        END square;
      10    0    D
      11     0    D            BEGIN
      12    0    $0016A        a := 55;
      13    0    $00174        l := square (a)
      14    0    $00180      END Beispiel.

Global variables:
                   $00002      l
                   $00000      a

Die erste Spalte enthält durchlaufende Zeilennummern für den Text. Dann folgt
ein Zähler für die Schachtelungstiefe von  Prozeduren  und  Modulen,  dessen
Nutzen Sie bei etwas komplizierteren  Programmen  als  dem  obigen  Beispiel
erkennen werden.

Die dritte Spalte gibt die Adresse des Zeilenanfangs im Codemodul an. Diese
Angabe ist immer relativ zum Modulanfang zu verstehen. Die gleiche relative
Adresse meldet Ihnen das System auch, wenn ein Laufzeitfehler auftritt - im
Protokoll können Sie so auf einen Blick die Fehlerzeile orten.  (Eine  andere
Möglichkeit der Fehlersuche bietet allerdings der Scanner - siehe Kapitel 2.5
'Debugger'.) Wenn Deklarationszeilen übersetzt werden, erscheint statt einer
Adresse ein "D" im Protokoll.

Durch das Einfügen der zusätzlichen Spalten in das Protokoll passen die fol~
genden Zeilen des Programmtextes oft nicht mehr komplett auf eine Zeile von
80 Zeichen. Der Compiler bricht dann im Protokoll den Rest der Zeile um.
Wenn Sie allerdings das Protokoll (z.B. auf einem Drucker) mit mehr als 80
Zeichen Breite ausgeben wollen, können Sie das Format im Parameter-Menü
auf andere Zeilenlängen einstellen.

Am Schluß der Protokolldatei folgt eine Liste der globalen Variablen mit den
jeweiligen relativen Adressen (die erste Variable liegt auf der rel. Adresse 0).

Die Startadressen der globalen Variablen und der Module können Sie durch
verschiedene  Funktionen  in  den  Modulen  Loader  und  ModCtrl  ermitteln
(Beispielprogramme in Ordnern DEMO & UTILITY: GPA, ModList und TraceMod).
In  der  Shell  werden  durch  Alternate-R  jedes  vorhandene  Modul  sowie  die
Startadressen und Längen des Codes angezeigt, ebenso wie mit ModList.
2.5  Bedienung: Debugger                                                 2 - 53
________________________________________________________


2.5    Debugger

Megamax  Modula  unterstützt  Sie  bei  der  Fehlersuche  durch  spezielle
Debugging-Funktionen  (die  Übersetzung  "Entwanzen"  kennen  Sie  vermutlich
schon). Ein spezielles  Debugger-Programm  werden  Sie  allerdings  vergeblich
suchen - beim Suchen helfen Ihnen der Compiler persönlich und das Imple~
mentations-Modul Debug. Diese Debug-Funktionen ersparen Ihnen die übliche
Fehlersuche bei compilierten Sprachen durch Einfügen diverser Testausgaben in
den Programmtext; sie helfen auch beim Aufspüren vertrackter Probleme.

Für  "harmlosere"  Fälle  bietet  Megamax  Modula  eine  weitere  Hilfe  bei  der
Fehlersuche:  das  Auffinden  der  Programmstelle  im  Test,  an  der  ein
Laufzeitfehler  auftrat.  Diese  Scan-Funktion  ist  im  letzten  Abschnitt  dieses
Kapitels beschrieben.


Übersetzen im Debug-Modus

Wollen Sie ein Programm 'debuggen', fügen Sie bitte als erstes ein 'IMPORT
Debug' in die Importliste ein (falls das Programm im TOS-Modus läuft, also die
Endung MOS oder MTP hat, importieren Sie besser TOSDebug). Das Modul
Debug enthält die Laufzeitfunktionen, die bei der Fehlersuche benötigt werden,
und muß daher im RAM zur Verfügung stehen.

Mit der Compiler-Option (*$D+*) im Programmtext schalten Sie den Compiler
in  den  Debug-Modus  um.  Für  alle  Programmzeilen,  die  in  diesem  Modus
übersetzt werden, erzeugt der Compiler zusätzlichen Code, so daß diese Zeilen
schrittweise,  mit  Ausgabe   des   Programmtextes   und   der   berechneten
Ausdrücke, ausgeführt werden können.

Natürlich  braucht  dieser  zusätzliche  Code  auch  zusätzlichen  Platz  im
übersetzten Modul. Außerdem ist die Ausführung von Programmen im Debug-
Modus wesentlich langsamer als im Normalfall - das 'Debuggen' einer 5000
mal durchlaufenen Schleife beschert Ihnen nicht nur jede Menge Bildschirm~
ausgaben sondern auch eine ausgedehnte Kaffeepause.

Sie  sollten  daher  die  Möglichkeit  nutzen,  gezielt  einzelne  Programmteile
zwischen (*$D+*) und (*$D-*) einzuschließen und zu untersuchen. Oft ist es
sinnvoll,  zunächst  das  Hauptprogramm  zu  überprüfen  und  herauszufinden,
welche Prozedur fehlerhaft ist. In einem weiteren Compilerlauf kann dann diese
Prozedur im Debug-Modus übersetzt werden.
2.5  Bedienung: Debugger                                                 2 - 54
________________________________________________________


Ausführen im Debug-Modus

Ein  Programm,  das  im  Debug-Modus  übersetzt  wurde,  enthält  zusätzliche
TRAP-Anweisungen,  die  das  Modul  'Debug'  abfängt.  'Debug'  sorgt  für  die
Ausgabe  der  ausgeführten  Zeilen  und  berechneten  Ausdrücke;  zusätzlich
erlaubt das Modul die Beeinflussung der Ausführung über die Tastatur.

Die  normale  Anzeige  jeder  Programmzeile  besteht  aus  der  Textzeile  des
Programms; darunter werden alle in dieser Zeile berechneten arithmetischen
Ausdrücke ('Expressions' in der Syntaxbeschreibung) in der Reihenfolge ihrer
Berechnung  ausgegeben.  Die  Reihenfolge  dieser  Ausgaben  ist  nicht  immer
einfach zu überblicken und soll am folgenden Beispiel erläutert werden:

IF ORD(a) = b+c THEN d:=e; f:=h+(2*g)END;

Nach  dem  IF  steht  laut  Modula-Syntax  eine  'Boolean  Expression',  die
ausgegeben  wird.  Bei  der  Berechnung  dieses  Ausdrucks  wird  jedoch  eine
weitere 'Expression' ausgerechnet, nämlich das Argument der Funktion ORD -
dessen Wert erscheint also als erste Ausgabe. Der Wert b+c wird dagegen
nicht  angezeigt,  denn  links  und  rechts  vom  Gleichheitszeichen  stehen
syntaktisch nur Simple Expressions.

Die  im  THEN-Teil  berechneten  Ausdrücke  erscheinen  natürlich  nur,  wenn
dieser Zweig ausgeführt wird. Der erste Ausdruck ist der auf <d> zugewiesene
Wert, also <e>. Bei der Berechnung des Ausdrucks, der auf <f> zugewiesen
wird, ist wiederum ein zusätzlicher Ausdruck auszuwerten: In Klammern steht
laut Syntaxdiagramm wieder eine 'Expression'. Also wird erst der Wert <2*g>
ausgegeben, dann <h+2*g>.

Außer 'Expressions' werden noch die Werte von Variablen angezeigt, die als
Parameter an Prozeduren übergeben werden.

Allgemeiner Tip: Wenn mehr (oder weniger) Werte ausgegeben werden, als Sie
erwarten,  sehen  Sie  im  Syntaxdiagramm  nach,  wo  wirklich  'Expressions'
stehen. Um die Ausgabe eines Teilausdrucks zu erzwingen, ist es oft möglich,
ihn  in  Klammern  zu  setzen  -  innerhalb  der  Klammern  wird  wieder  eine
vollständige Expression erwartet und ausgegeben.
2.5  Bedienung: Debugger                                                 2 - 55
________________________________________________________


Leertaste   veranlaßt Ausführung und Ausgabe der nächsten Zeile
            oder schaltet von laufender Ausführung auf Einzelschritt.
<Return>    schaltet von Einzelschritt auf laufende Ausführung.
<H>         wählt Ausgabe von Skalaren als Hexadezimalzahlen.
<D>         wählt Ausgabe von Skalaren als Dezimalzahlen.
<S>         Eingabe einer Schrittweite: die eingegebene Anzahl Zeilen
            wird ohne Ausgaben (schneller) ausgeführt.
<A>         aktiviert die Ausgabe wieder, wenn sie durch <S>
            unterdrückt wurde.
<L>         schaltet zusätzliche Ausgabe der Zeilenadresse zu jeder
            Programmzeile ein/aus.
<R>         veranlaßt einmalige Ausgabe aller CPU-Register.

Die  gleichen  Kontrollfunktionen  können  statt  von  der  Tastatur  auch  vom
laufenden Programm aus umgeschaltet werden. Dazu können Steuervariablen
aus dem Modul 'Debug' importiert und verändert werden. Das erfordert zwar
einige zusätzliche Anweisungen im Programm, erleichtert aber manchmal die
gezielte  Fehlersuche  sehr  -  z.B.  wenn  die  Debug-Ausgaben  erst  aktiviert
werden  sollen,  wenn  eine  Variable  einen  bestimmten  Wert  hat  oder  eine
Prozedur mit vorgegebenen Argumenten aufgerufen wurde. Die Funktion der
Steuervariablen im einzelnen:

Continous:  BOOLEAN   =  "laufende Ausführung ohne Warten"
Active:     BOOLEAN   =  "folgende <Step> Schritte ohne Anzeige ausführen"
Step:       LONGCARD =   Anzahl der Schritte, die ohne Anzeige auszu~
                             führen sind (zusätzlich muß Active = FALSE sein)
LineAddr:   BOOLEAN   =  "zu jeder Programmzeile Adresse ausgeben"
Hex:        BOOLEAN   =  "Skalare als Hexadezimalzahlen ausgeben"


Der Scanner - Suchen der Fehlerposition

In vielen Fällen werden Sie das Debug-Modul zur Fehlersuche
aber gar nicht benötigen - es gibt noch eine einfache und oft
wesentlich  schnellere  Möglichkeit,  Programmierfehlern  auf  die
Spur zu kommen. Oft genügt es ja zu wissen, welche Stelle des Programms
(im  Text)  gerade  ausgeführt  wurde,  als  ein  Laufzeitfehler  auftrat.  Dabei
unterstützt Sie der 'Scanner', den Sie auf der Shell-Arbeitsfläche als Lupe
abgebildet sehen.

Hinter dem Scanner verbirgt sich in Wirklichkeit wiederum  der  Compiler  -
allerdings  in  einer  Betriebsart,  die  keine  Codedatei  erzeugt,  sondern  nur
so  lange  'ins  Blaue'  übersetzt,  bis  eine  bestimmte  Adresse  im  erzeugten
Codemodul erreicht ist. Dann stoppt der Scanner und ruft den Editor auf, um
die erreichte Textstelle zu zeigen.
2.5  Bedienung: Debugger                                                 2 - 56
________________________________________________________


Wenn  ein  Laufzeitfehler  auftritt,  ermittelt  das  Modula-System,  in  welchem
Modul und auf welcher relativen Adresse innerhalb des Moduls die Ausführung
unterbrochen wurde. Sie können wählen:

* Exit, um die angezeigte Fehlerposition im Programmtext zu suchen.
* Back, um statt der angezeigten Fehlerposition die Position des Aufrufers zu
  sehen (s.u.);
* Frwd, um entsprechend wieder die Position des nächsttieferen Aufrufs zu
  bekommen.

Nach Wahl von Exit haben Sie nochmals die Möglichkeit, durch Quit zur Shell
zurückzukehren oder durch Cont das Programm doch fortzusetzen. Durch Edit
schließlich starten Sie den Scanner, der Ihnen die gefundene Fehlerstelle dann
im Editor präsentiert.

Gelegentlich  müssen  Sie  noch  etwas  mehr  tun,  um  den  Ursprung  eines
Laufzeitfehlers zu finden: Unter  Umständen  ruft  das  fehlerhafte  Programm
eine Prozedur (evtl. in einem anderen Modul) mit falschen Parametern auf, und
erst dort wird der Fehler ausgelöst. Dann interessiert Sie natürlich nicht die
Position in der Prozedur, sondern die des falschen Aufrufs. In diesem  Fall
klicken Sie in der ScannerBox bitte nicht Exit, sondern Back an - eine neue
Scanner-Box  zeigt  Ihnen  Modulnamen  und  Adresse  des  Aufrufers.  Dieses
Rückverfolgen  zum  Aufrufer  können  Sie  wiederholen,  bis  das  'verdächtige'
Modul erreicht ist. Sind Sie in der Aufrufer-Kette zu weit 'geklettert', dann
können  Sie  mit  Frwd  wieder  tiefer  steigen.  Wenn  Sie  den  eigentlichen
Verursacher des Fehlers gefunden haben, wählen Sie Exit, und nach einem
Scannerlauf wird die Position in diesem Modul angezeigt.


Manuelles Starten des Scanners

Bei der oben beschriebenen Bedienung des Scanners ist das Scanner-Symbol
auf der Arbeitsfläche noch gar nicht benutzt worden. In zwei Fällen kommt
dieses Symbol zur Anwendung:

* Wenn Sie nach einem Laufzeitfehler eine Adresse aus der  Aufruferkette
ausgewählt haben (durch 'Back'/'Forward'), die sich nach dem Scannen nicht
als  der  eigentliche  Verursacher  des  Fehlers  herausstellt.  In  diesem  Fall
möchten  Sie  wahrscheinlich  noch  eine  andere  Adresse  aus  der  Kette
untersuchen.

* Wenn nach einem fatalen Laufzeitfehler die Shell und der  Scanner  nicht
mehr funktionieren (etwa nach Überschreiben wichtiger Speicherbereiche). Die
Fehlerposition im Code sollten Sie in jedem Fall noch erfahren; nach einem
Neustart  der  Shell  läßt  sich  die  zugeordnete  Textstelle  dann  durch  einen
manuellen Scanner-Aufruf (mit Eingabe der Adresse von Hand) feststellen.
2.5  Bedienung: Debugger                                                 2 - 57
________________________________________________________


Wollen Sie erneut die Aufrufkette zum vorangegangenen Laufzeitfehler sehen,
dann müssen Sie das Scanner-Symbol bei festgehaltener Shift-Taste anwählen
(z.B. mit Shift-S). Sie sehen dann die oben beschriebene Scanner-Box.

Übergeben Sie dagegen eine Datei an den Scanner, indem Sie sie auf das
Symbol schieben, so bekommen Sie die Möglichkeit, eine Fehleradresse  von
Hand einzugeben. Gemeint ist hier immer die relative Adresse innerhalb des
Moduls, wie sie auch nach Laufzeitfehlern angezeigt wird. Um die Arbeitsdatei
zu scannen, brauchen Sie das Scanner-Symbol nur doppelt anklicken.

Fragt der Scanner nach der relativen Position, ist der vorher beim Laufzeit~
fehler angezeigte Wert einzugeben. Dabei ist zu beachten, daß der Wert, wie
bei  der  Anzeige,  mitsamt  dem  "$"-Zeichen  eingegeben  wird,  da  dies  eine
Hexadezimalzahl kennzeichnet.
2.5  Bedienung: Debugger                                                 2 - 58
________________________________________________________





















                               Auch diese Seite war zu kostbar,
                                     um leer zu bleiben.
2.6  Bedienung: Linker                                                    2 - 59
________________________________________________________


2.6    Linker

Funktion

In Kapitel 1.4 haben wir schon beschrieben,  warum  das  Megamax  Modula-
System eigentlich ohne Linker auskommt: Der Loader als Teil der Entwicklungs~
umgebung sorgt für automatisches Load Time Linking, wenn Sie aus der Shell
ein Programm starten.

Wollen Sie  aber  ein  Modula-Programm  als  eigenständige  TOS-  oder  PRG-
Anwendung verwenden, dann muß es komplett mit allen benutzten Modulen in
einer  Codedatei  abgelegt  werden,  damit  das  TOS  damit  zurechtkommt.
Außerdem müssen noch einige zusätzliche Anweisungen eingefügt werden, um
für die Module die gleiche Laufzeitumgebung bereitzustellen, wie sie bei Aufruf
aus der Shell herrscht.

Eine solche Codedatei erzeugt der  Linker  -  erfreulicherweise  kann  er  das
vollautomatisch.  Sie  übergeben  ihm  nur  den  Namen  des  Hauptmoduls;  der
Linker lädt alle importierten Module dazu und fügt zusätzlich  ein  spezielles
Initialisierungs-Modul  ein.  Das  resultierende  Programm  kann  dann  völlig
unabhängig  vom  Modula-System,  z.B.  unter  dem  GEM-Desktop,  gestartet
werden;  daher  können  Sie  Programme  in  dieser  Form  auch  an  Dritte
weitergeben, die das Megamax Modula-System nicht besitzen  (siehe  Kapitel
1.5).

Bedienung

Der Linker wird aufgerufen wie alle anderen Systemprogramme: Legen Sie mit
der Maus eine Code-Datei auf dem Linker-Symbol auf der Arbeitsfläche ab
(oder klicken Sie das Linker-Symbol an, um die Arbeitsdatei zu übergeben).
Bevor Sie den Linker starten, sollten Sie aber überprüfen, ob folgende Voraus~
setzungen erfüllt sind:

* Von allen Modulen, die in das Programm importiert werden, muß das über~
setzte Implementationsmodul vorhanden sein. Zusätzlich werden evtl. weitere
Module benötigt (siehe folgenden Abschnitt Konfigurationsmodule). Die Imple~
mentationsmodule werden auf den Pfaden der ImpPath-Liste (siehe Kap. 2.2,
Batch-Dateien) gesucht.

* Das fertig gelinkte Programm wird auf dem Pfad gespeichert, der für das
übergebene Hauptmodul angegeben wurde. (Sie können hier bewußt einen Pfad
-  durch  Doppelklick  auf  das  "aktuelle  Datei"-Fenster  oder  Control-P  -
angeben, auf dem das Hauptmodul gar nicht zu finden ist, um die Ausgabe zu
lenken;  das  Hauptmodul  wird  dann  auf  allen  Pfaden  der  ModPath-Liste
gesucht).  Auf  der  Zieldiskette  muß  genügend  Platz  sein  -  durch  die
zusätzlichen Module wird das  gelinkte  Programm  im  allgemeinen  wesentlich
größer als das ursprüngliche Modul.
2.6  Bedienung: Linker                                                    2 - 60
________________________________________________________


Wenn keine Schwierigkeiten auftreten, baut der Linker auf dem Bildschirm eine
Liste der importierten Module auf. Zuerst werden dabei stets die Konfigura~
tions-Module (s.u.) aufgenommen, gefolgt von ihren Importen. Dann folgen das
von Ihnen angegebene Hauptmodul und dessen Importe. Schließlich meldet der
Linker den erfolgreichen Ablauf und speichert das fertige Programm ab.

Fertig - mehr zu Bedienen gibt's in der Regel nicht! Es sei denn, Sie werden
mit einer der folgenden Fehlermeldungen konfrontiert:


Fehlermeldungen

Alle Meldungen beginnen mit der Angabe, welches Modul das Problem ausgelöst
hat  und  von  welchem  anderen  Modul  es  benötigt  wurde:  "Importing
<FehlerModul>  into  <KundenModul>".  Dann  folgt  eine  Fehlerbeschreibung.
Allgemein gilt: Der Linker interessiert sich immer für übersetzte Implemen~
tationsmodule - alle Probleme können sich also nur auf diese Dateien beziehen.

Module not found
    Das  übersetzte  Implementationsmodul  wurde  auf  keinem  der  Pfade
    gefunden, die in der IMPPATH-Pfadliste in der Shell-Info definiert sind.
Wrong module format
    Die  geladene  Datei  ist  kein  korrekt  aufgebautes  Implementationsmodul;
    vermutlich ist die Datei beschädigt.
Error in relocating list
    Die  Relozierliste  (Bestandteil  jedes  übersetzten  Moduls)  ist  fehlerhaft;
    vermutlich ist die Datei beschädigt.
Bad module layout
    Das  Modul  wurde  mit  einer  alten  Compilerversion  übersetzt,  die  ein
    anderes Dateiformat erzeugt. Modul neu übersetzen!
File is damaged
    Beim Laden des Moduls ist ein Lesefehler aufgetreten.
Wrong module version
    Die gefundene Version des Moduls paßt zu einem anderen Definitionsmodul
    als beim Übersetzen des Kundenmoduls vorlag. (Das Modul exportiert nicht
    genau die Bezeichner, die das Kundenmodul erwartet.) Ggf. beide Module
    neu übersetzen!
Out of memory
    Der Hauptspeicher reicht nicht aus.  Evtl.  vorhandene  Accessories  oder
    RAM-Disk entfernen.
Too many modules (list overflow)
    Mehr als die in den Parametern eingestellte Anzahl Module sollen gebunden
    werden. Erhöhen Sie den Wert Max. Module unter Parameter/Linker und
    wiederholen Sie den Linker-Aufruf.

Außerdem  sind  I/O  Error-Meldungen  möglich.  Sie  enthalten  jeweils  eine
Beschreibung des Fehlers und beziehen sich stets auf die Ausgabe-Datei.
2.6  Bedienung: Linker                                                    2 - 61
________________________________________________________


Linker-Optionen

Beim  Menüpunkt  Parameter
kann unter Linker eine Dia~
logbox geöffnet werden, die
das Einstellen aller Optionen
beim Linken zuläßt.

In den acht Treiber-Feldern
werden  die  Initialisierungs-
und    Konfigurations-Module
eingetragen, die weiter unten
ausführlich  behandelt  wer~
den.  Die  Stackgröße  wird
ebenfalls später erläutert. Der Wert hinter Max. Module bestimmt, wie viele
Module maximal  zu  linken  sein  werden.  Ist  dieser  Wert  zu  klein  gewählt,
meldet der Linker einen Fehler und Sie müssen den Wert erhöhen. Er sollte
aber auch nicht unnötig groß gewählt werden, weil je nach seiner Größe mehr
oder  weniger  Speicherplatz  von  vornherein  vom  Linker  reserviert  wird.
Besonders, wenn mangels Speicher öfter die Fehlermeldung Out of memory
beim Linken erscheint, sollten Sie diesen Wert so klein wie möglich halten.


Treiber- bzw. Konfigurations-Module

Zusätzlich zu den Modulen, die Sie explizit (durch IMPORT-Anweisungen) in
Ihren  Programmen  benutzen,  kann  der  Linker  noch  weitere  Module  in  die
Code-Datei einbinden. Mindestens ein solches Modul wird (fast) immer benötigt,
um vor dem Start des Modula-Programms die Laufzeitumgebung vorzubereiten.
Weitere  Module,  die  mitgeliefert  wurden,  stellen  Ausgabefunktionen  auf
unterster Ebene für TOS- oder GEM-Umgebung bereit.

Das System ist bereits so konfiguriert, daß alle Programme 'gelinkt' werden
können, ohne daß Sie sich um diese zusätzlichen Module kümmern müßten. Sie
können  die  Konfiguration  dieser  Module  aber  von  der  Shell  aus  mit  dem
Menüpunkt Parameter/Linker einstellen. In der Dialogbox (s.o.) existiert eine
Liste  für  mit  acht  Treibern.  Vor  jeden  dieser  Treiber  können  Sie  durch
Anklicken ein Häkchen setzen oder löschen - nur die so markierten Modul~
namen werden beim Linken eingebunden. Normalerweise  sind  fünf  der  acht
möglichen Namen eingetragen:

M2Init sorgt für die Vorbereitung der Laufzeitumgebung. Dieses Modul muß in
jedem Codefile enthalten sein - bitte nur 'abschalten', wenn es extra verlangt
wird, wie z.B. beim Linken von MoreMem (UTILITY-Ordner) oder wenn  Sie
selber die Initialisierung in Ihrem Modul vornehmen wollen.
2.6  Bedienung: Linker                                                    2 - 62
________________________________________________________


GEMError übernimmt die Behandlung von Laufzeitfehlern. Wenn dieses Modul
vorhanden ist, werden Laufzeitfehler in einer Alert-Box mit Fehlerbeschreibung
und -position angezeigt. GEMError kann nur sinnvoll bei keine Optimierung oder
verkürzende Optimierung mit eingelinkt werden. Wird vollständig optimiert, ist
statt dessen SimpleError einzubinden.

SimpleError ist eine einfachere Fehlerbehandlung als GEMError, die, falls über~
haupt ein Fehlerabfangen erwünscht ist, bei vollständig optimierten Programmen
gewählt werden muß.

Um Platz zu sparen, können Sie GEMError bzw. SimpleError auch weglassen -
dann erscheinen bei Laufzeitfehlern nur die allseits bekannten Bömbchen.

GEMIO enthält Ausgabefunktionen, auf die sich das InOut-Modul stützt. Diese
Funktionen lenken die Ausgabe auf ein Fenster, wie Sie es vom Arbeiten mit
der  Megamax  Modula-Shell  kennen.  Leider  ist  die  Unterstützung  dieser
'hübschen' Ausgabe recht aufwendig, und die fertige Code-Datei wird relativ
lang.  Daher  können  Sie,  wenn  Ihr  Programm  sonst  keine  GEM-Funktionen
benutzt,  ohne  Programmänderung  wahlweise  auch  TOS-Ausgabe  über  das
TOSIO-Modul wählen:

TOSIO  enthält  die  gleichen  Ausgabefunktionen  wie  GEMIO,  allerdings  für
Ausgabe auf dem TOS-Bildschirm (schwarz auf komplett weißem Grund mit
Textcursor, keine GEM-Funktionen, keine Maus). Wenn Sie dieses Modul statt
GEMIO aktivieren, geben alle InOut-Funktionen auf dem TOS-Bildschirm aus.
Damit das GEM-Desktop die richtigen Initialisierungen beim Starten durchführt,
sollte das fertig gebundene Programm von '.PRG' in '.TOS' umbenannt oder von
vornherein  das  Modul  durch  die  Option  $E  MOS  im  Quelltext  als  TOS-
Programm klassifiziert werden.

Achtung: TOSIO verwendet die BIOS-Funktionen zur Bildschirm-Ein-/Ausgabe
und erlaubt somit keine Datei-Umleitung (I/O-Redirection) von außen, z.B. über
eine  Command-Shell.  Dafür  kann  solch  ein  Programm  nicht  einfach  durch
Eingabe von Control-C abgebrochen werden.

GEMDOSIO ist, ebenso wie TOSIO, für TOS- und TTP-Programme zuständig.
Es  erlaubt  die  Umlenkung  von  Ein-/Ausgaben  über  das  Modul  InOut  von
außerhalb  (beispielsweise  über  eine  Command-Shell)  und  den  Programm~
abbruch über Control-C, da die Ein-/Ausgaben über die GEMDOS-Funktionen
geschehen. Ist Ihnen der Sinn dieser Anwendung nicht klar, verwenden Sie
besser TOSIO!

Nochmal in Kurzform: Benutzen Sie M2Init immer; entweder GEMError oder
SimpleError  wenn  ordentliche  Fehlermeldungen  gewünscht  sind;  entweder
GEMIO,  TOSIO  oder  GEMDOSIO,  wenn  InOut-Funktionen  benutzt  werden.
(Falls das Programm InOut gar nicht benutzt, sollten diese IO-Module weg~
gelassen werden, um das Programm nicht unnötig zu vergrößern.)
2.6  Bedienung: Linker                                                    2 - 63
________________________________________________________


Komprimierung (Optimierung) des zu erzeugenden Programms

Durch die Wahl einer der vier gezeigten
Optionen läßt sich bestimmen, inwieweit
die   zusammengefügten   Module   im
erzeugten     Programm     komprimiert
werden sollen.

Die erste Einstellung keine Optimierung fügt die Module ohne Komprimierung
zusammen. Zudem werden die Informationen über alle Module mit eingebunden,
die  benötigt  werden,  wenn  das  Loadtime  Linking  vom  gelinkten  Programm
verwendet werden soll. Diese Option ist also zu wählen, wenn ein Programm
erzeugt wird, das den Loader importiert, um andere Module starten zu können,
z.B. bei der Shell dieses Systems (MM2Shell).

Alternativ  zu  keiner  Optimierung  können  auch  nur  Prozedurnamen  entfernt
werden.  Dadurch  bleiben  die  Module  vollständig  erhalten,  nur  werden  die
Symboltabellen, die die einzelnen Prozedurnamen enthalten, entfernt. Loadtime
Linking ist dann weiterhin möglich, nur ist das Scanning (s. Kap 2.5, Debugger)
und die Anzeige der Prozedurnamen bei Laufzeitfehlern nicht mehr möglich.
Diese Komprimierung ist  für  Sie  meist  nicht  von  Interesse.  Lediglich  beim
Linken der Shell (sofern Sie daran Änderungen vorgenommen haben) sollten
Sie sie anstatt keiner Optimierung anwenden,  weil  Sie  dabei  ca.  10  KByte
einsparen.  Da  Sie  im  Allgemeinen  bei  Fehlern  in  den  MOS-Modulen  keine
Korrekturen vornehmen können, können Sie bei diesen Modulen ja ruhig auf die
Möglichkeit zum Scanning verzichten. Auf Module, die per Loadtime Link von
der Shell gestartet werden, hat dies keinen Einfluß.

Die  Option  Prozedurnamen  erhalten  erzeugt  kompaktere  Programme.  Dabei
werden alle Funktionen entfernt, auf die es keine Referenz zur Laufzeit gibt.
Das  gelinkte  Programm  enthält  demnach  nur  Module  mit  Funktionen,  die
aufgerufen werden können und Module mit exportierten Variablen, die von den
benötigten Prozeduren benutzt werden. Zusätzlich enthalten sind, wie bei den
vorigen Optionen,die Informationen über die Module, die für eine Laufzeitfehler~
analyse  (Anzeige  der  Prozedur-  und  Modulnamen  und  der  aufrufenden
Prozeduren) mittels des Moduls GEMError benötigt werden. In dieser Form ist
kein Load-Time-Linking vom gelinkten Programm aus möglich.

Wenn weder vom Loadtime Linking (Starten von Modulen mittels des Loaders),
noch von der komfortablen  Fehleranalyse  (Import  von  GEMError)  Gebrauch
gemacht  werden  soll,  kann  die  letzte  Einstellung  vollständige  Optimierung
gewählt  werden.  Sie  erzeugt  die  kompaktesten  Programme,  indem  im
Unterschied  zur  vorigen  Option  die  Informationen  zur  Fehleranalyse  weg~
gelassen  werden.  Damit  eventuelle  Fehler  trotzdem  ordentlich  angezeigt
werden, muß SimpleError statt GEMError eingebunden werden.
2.6  Bedienung: Linker                                                    2 - 64
________________________________________________________


Vorsicht:

Bei der vollständigen Optimierung entfernt der Linker alle Module vollständig,
die zwar importiert werden, aus denen aber keine Prozeduren oder Variablen
wirklich benutzt werden. Das heißt: Importieren Sie ein Modul, das in seinem
Initialisierungscode (Körper) lediglich Variablen anderer Module initialisiert oder
importierte Prozeduren dort aufruft, verschwinden diese Anweisungen!

Dieser  Effekt  tritt  nur  beim  optimierten  Linken  auf.  Haben  Sie  also  ein
Programm, das ungelinkt unter der Shell oder nicht-optimiert gelinkt fehlerfrei
läuft, optimiert gelinkt aber nicht funktioniert, prüfen Sie, ob die beschriebene
Situation bei Ihnen vorkommt. Sie können es auch daran erkennen, daß solche
Module beim Linken zwar erst beim  Einladen  angezeigt  werden,  dann  aber
wieder vom Bildschirm gelöscht werden, weil sie vollständig entfernt wurden.

Um  dies  zu  verhindern,  müssen  Sie  die  wegoptimierten  Module  mit  der
Direktive B+ übersetzen, entweder durch $B+ im Quelltext oder durch -B in
der Eingabezeile für Direktiven in der Compiler-Parameter-Box.

Zusammenfassend seien pauschal diese Regeln zu befolgen:

* Accessories sollten möglichst kurz sein und dürfen nie mit einem Fehler
abbrechen,  da  dann  das  gesamte  System  nicht  mehr  funktionsfähig  ist.
Deshalb ist am besten nach eingehendem Testen das Modul mit der Option
$R-  zu  compilieren,  um  Platz  zu  sparen,  und  das  Programm  dann  mit
vollständiger Optimierung und  ohne  Fehlermodule  zu  linken  (also  in  Linker-
Optionen nur M2Init aktivieren).

* Die Shell MM2Shell wird mit der Einstellung keine Optimierung  oder  nur
Prozedurnamen  entfernen  und  den  Modulen  M2Init,  GEMIO  und  GEMError
gebunden. Max. Module sollte den Wert 100 haben. Falls der Linker nicht linken
will,  weil  der  freie  Speicher  nicht  ausreicht,  entfernen  Sie  die  resident
geladenen  Programme  (z.B.  Compiler  und  Editor).  Wenn  das  nicht  reicht,
entfernen Sie Ihre Accessories, residente Programme im AUTO-Ordner und
ggf. auch eine vorhandene RAM-Disk (dann müssen die Suchpfade ImpPath und
ModPath  ggf.  die  Pfadnamen  für  die  IMP-  und  MOD-Dateien  auf  den
Laufwerken A: oder B: enthalten, damit die Modulcodes dann von Disk geladen
werden können).

* Sonstige Programme können in der Regel mit der vollständigen Optimierung
gelinkt werden, um zu erreichen, daß die Programme möglichst wenig Platz auf
Disk und im Speicher beim Ausführen belegen. Zur Sicherheit sollte allerdings
das Modul SimpleError mit eingebunden werden, damit in einem unerwarteten
Fehlerfall das Programm sich nicht gleich mit Bömbchen verabschiedet, sondern
statt dessen eine Meldung zeigt, um was für einen Fehler es sich handelt. Ist
allerdings  mit  Laufzeitfehlern  zu  rechnen,  ist  es  sinnvoller,  verkürzende
Optimierung zu wählen und GEMError einzubinden. Dann ist bei einem Fehler
2.6  Bedienung: Linker                                                    2 - 65
________________________________________________________


die  Lokalisation  der  Ursache  einfacher.  Da  aber  in  diesem  Fall  meist  nur
Prozedurnamen, aber kein 'Offset' zum nachträglichen Scannen in der Shell
angezeigt werden kann, ist im ungünstigsten Fall keine Optimierung zu wählen.
Dann werden auch die Offsets bei Fehlern immer angezeigt. In der Shell kann
dann z.B. durch Ziehen des Quelltextes des zu scannenden Moduls auf die
Scan-Box der Offset eingegeben werden, um den Scanner zu aktivieren.

* Bei allen normalen Programmen, auch Accessories, muß M2Init als erstes
Treibermodul  eingebunden  werden,  weil  dieses  Modul  dafür  sorgt,  den
überflüssigen Speicher freizugeben, die globalen Variablen (das BSS Segment)
zu löschen und die einzelnen Module zu initialisieren (die Modulkörper werden
alle nacheinander aufgerufen).

*  Es  ist  immer  darauf  zu  achten,  daß  die  Module  GEMIO,  TOSIO  oder
GEMDOSIO nur dann eingebunden zu werden brauchen, wenn das Modul InOut
verwendet wird. Ansonsten erzeugt das Einbinden dieser Module nur unnötig
lange Programme.


Stack-Größe

Ebenso wie bei Modulen, die unter der Shell mit Loadtime-Linking gestartet
werden, kann die Stackgröße auch für gelinkte Programme bestimmt werden
(siehe auch Kap. 2.2, Kommandozeile). Ist der Wert Null eingetragen, wird die
Standard-Größe verwendet, die in M2Init bestimmt ist (normalerweise  8192
Bytes). War beim Starten eines Moduls unter der Shell ein größerer Stack
nötig, so ist dieser in der Regel genauso beim Linken in der Linker-Parameter-
Box einzustellen. Ist der Stack des gelinkten Programms zu klein, wird eine
entsprechende Fehlermeldung während des  Programmlaufs  angezeigt,  sofern
GEMError bzw. SimpleError mit eingebunden wurde.


Binden von Accessory-Programmen

Übrigens: Accessories (Endung ACC) können ohne weiteres mit dem Linker
erzeugt werden, ihre Endung muß nur ggf. auf ACC angepaßt werden, wenn
nicht schon im Programmtext mit einer Zeile wie (*$E MAC *) die Endung für
den Linker vorbereitet wird. Mit Hilfe der Funktion PrgCtrl.Accessory kann das
Programm gar abfragen, ob es nun  als  normales  PRG-Programm  oder  als
Accessory  mit  Endung  ACC  gestartet  wurde,  und  entsprechend  reagieren
(Accessories müssen sich zusätzlich in die Menüleiste eintragen und dürfen
nicht terminieren!).
2.6  Bedienung: Linker                                                    2 - 66
________________________________________________________


Fast Load-, Fast Code- und Fast Memory-Flags

In neueren TOS-Versionen werden drei neue Kennungen im Programmkopf von
gelinkten  Programmen  ausgewertet.  Das  Fast  Load-Flag  (seit  TOS  1.4)
bestimmt, ob ein Programm es nötig hat, daß beim Start seine TPA gelöscht,
also mit Null-Bytes beschrieben werden soll. Die  TPA  ist  der  größte  freie
Speicherblock, in dem das Programm selbst auch steht. Sie ist Bestandteil des
Heaps; dem Speicher, der mit dem Storage-Modul angefordert werden kann.
Ist das Flag gesetzt, wird die TPA  nicht  gelöscht.  Modula-Programme,  die
unter der Shell vom Loader gestartet werden, erhalten den Heap nie gelöscht,
so brauchen Sie es in der Regel auch nicht, wenn sie gelinkt gestartet werden.
Daher kann das Fast Load-Flag immer aktiviert bleiben.

Die Flags für Fast Code und Fast Memory bestimmen bei Atari TT-Rechnern,
ob  der  "schnelle"  Speicher  dieses  Computers  mitbenutzt  werden  darf.
Einschränkungen  gibt  es  hier  nur  selten,  beispielsweise,  wenn  Sie  die
Videospeicher-Adresse in einen anderen Bereich legen wollen, denn dies darf
nur im "normalen" Speicher der ersten 16 MByte geschehen - das Fast RAM
liegt aber oberhalb der ersten 16 MB.

Fast Code bestimmt, ob der Programmcode im schnellen Speicher  ablaufen
darf,  Fast  Memory,  ob  bei  Speicheranforderungen  (vom  Heap)  auch  der
schnelle Speicher vergeben werden darf. Funktioniert ein Programm nicht auf
dem TT, sollten Sie zuerst diese Flags probeweise abschalten.


Arbeitsweise des Linkers

  Bekanntermaßen wird der Linker dazu verwendet, um aus einem Hauptpro~
gramm und seinen Bibliotheken ein Programm zu erzeugen, das auch außerhalb
der Megamax-Shell ausführbar ist.

  Die Mindestanforderung an den Linker ist dabei, das Hauptmodul mit allen
importierten  Modulen  zusammenzufügen  und  die  Adressen  der  "externen"
Prozeduren und Variablen zu verketten. Außerdem müssen die Relozierinfor~
mationen  der  einzelnen  Module  vom  für  das  Loader-Modul  verständlichen
Format in das TOS-Format umgewandelt werden. Dann kann daraus eine Datei
erzeugt werden, in der am Anfang noch Informationen abgelegt werden, wie
lang der Programm- und der Variablenbereich sind und wo im Programmcode
der Körper des Hauptmoduls liegt, also des Teils, in dem mit der Ausführung
begonnen werden soll.

  Nur reicht das in der Regel nicht aus, denn so wird zwar das Hauptmodul
beim Starten des gelinkten Programms ausgeführt, aber die ihm untergeordne~
ten Module wurden nicht initialisiert. Es ist notwendig, zusätzlich die Körper
der anderen Module vorher auszuführen. Aus diesem Grund legt der Linker
2.6  Bedienung: Linker                                                    2 - 67
________________________________________________________


zwischen dem  Programmcode  und  der  Reloziertabelle  noch  eine  Liste  aller
Adressen der Körper ab, und zwar in ihrer hierarchischen Reihenfolge, mit
dem tiefsten Modul beginnend. Damit diese Körper nun ausgeführt werden, muß
ein weiteres Modul eingebunden werden; wir empfehlen M2Init.

  M2Init, dessen Körper als erstes Modul ausgeführt wird, weil es vom Linker
als Hauptmodul verstanden wird, sorgt außerdem für richtige Initialisierung des
Programms. Zuerst ermittelt es, ob es  als  Accessory  gestartet  wurde;  in
diesem Fall fordert es erst einmal Speicher an, um ihn als Stack verwenden
zu können. Im anderen Fall hat es bereits den gesamten freien Speicher als
Stackbereich erhalten und verkleinert ihn deshalb erstmal und gibt den unbe~
nutzten Bereich an das System zurück.

  Der Linker hat dafür gesorgt, daß in dem Adreßregister A0 die Adresse der
Base-Page und in A1 die Adresse der Liste mit den Verweisen auf die Körper
der anderen Module übergeben werden. So ruft M2Init dann alle von ihm selbst
importierten Modulkörper auf (sie stehen zu Beginn der Liste, die mit einem
NIL-Zeiger abschließt) und dann eine Prozedur aus dem Modul MOSCtrl, um
ihr die Adresse einer Tabelle mitzuteilen, welche ebenfalls vom Linker erzeugt
wurde, und in welcher, sofern nicht vollständige Optimierung gewählt wurde,
die Informationen über alle vorhandenen Module enthalten sind (z.B. Modulname,
Adresse und Länge im Speicher, usw.). Diese Tabelle wird vom Modul ModBase
verwaltet und von ModCtrl und Loader mitverwendet. Sie wird z.B. benötigt,
um bei einer Fehleranzeige durch GEMError den Modulnamen  und  ggf.  den
Prozedurnamen zu ermitteln.

  Ist die Initialisierung des MOS-Systems abgeschlossen, werden die restlichen
Modulkörper  ausgeführt  (die  Liste  wird  fortgesetzt  und  wiederum  mit  NIL
abgeschlossen), wobei der letzte Körper das eigentliche Hauptmodul ist.

  Nun ist es theoretisch unnötig, immer die importierten  Module  vollständig
einzubinden, da normalerweise nicht alle Prozeduren (zumindest bei den mitge~
lieferten Bibliotheksmodulen) verwendet werden. Deshalb gibt es die Möglich~
keit, die Programme optimiert  zu  linken.  Beim  Megamax  Modula-2  gibt  es
zwei Stufen der Optimierung. Beide haben gemeinsam, daß alle Prozeduren, die
keinesfalls  benötigt  werden,  vor  dem  Zusammenbinden  aus  den  Modulen
entfernt werden. Ergibt sich dabei, daß trotz Import-Anweisung eines Moduls
aus diesem weder Prozeduren noch Variablen verwendet werden, wird sogar
das gesamte Modul nicht eingebunden (dies ist daran zu erkennen, daß solche
Modulnamen im Fenster nach dem Optimiervorgang wieder verschwinden). Dies
ist u.a. bei Modulen der Fall, die nur Konstanten enthalten (z.B. MOSGlobals).

  Soll ein Modul nicht komplett wegoptimiert werden können, obwohl es keine
Funktionen und Variablen exportiert, aber beispielsweise in seinem Modulkörper
Variablen, die es aus anderen Modulen importiert hat, initialisiert oder auch
dort importierte Funktionen aufruft, muß in seinem Quelltext - am besten zu
Beginn - die Compiler-Option $B+ aufgeführt werden!
2.6  Bedienung: Linker                                                    2 - 68
________________________________________________________


  Ob eine Prozedur benötigt wird, erkennt der Linker daran, daß er nachsieht
- ausgehend von jedem Modulkörper - welche Prozeduraufrufe darin vorkom~
men.  Diese  gefundenen  Prozeduren  werden  nun  wiederum  selbst  alle  auf
weitere Aufrufe überprüft (eine an sich ganz einfache Sache). Es werden dabei
auch Prozeduren ermittelt, die zwar als Aufrufe von aufgerufenen Prozeduren
gefunden werden, jedoch nie ausgeführt werden, weil eine damit verbundene
Bedingung niemals eintritt - aber dies kann der Linker nicht herausfinden und
optimiert sie deshalb nicht weg.

  Alle Prozeduren, die auf diesem Wege nicht gefunden wurden, werden als
nicht benötigt deklariert und somit beim  Binden  aus  den  Modulen  entfernt.
Lokale  Prozeduren  werden  übrigens  immer  zusammen  mit  ihren  globalen
Vätern behandelt. Es kann nicht erkannt werden, daß lokale Prozeduren nicht
benötigt werden. Es wird nur auf die globalen Rücksicht genommen und die
lokalen müssen mitziehen (informatisches Machtgefüge). Prozeduren, die auf
dem äußersten Scope von lokalen Modulen ihren Platz haben, werden natürlich
wie  globale  Prozeduren  behandelt.  Bitte  erwarten  Sie  aber  nicht,  daß  die
lokalen  Modulkörper  auch  entfernt  werden,  wenn  das  globale  Modul  keine
Variablen oder Prozeduren aus dem lokalen Modul verwendet!

  Die  beiden  Optimierungsmodi  unterscheiden  sich  nur  darin,  daß  beim
"vollständigen Optimieren" auch  die  Informationen  über  die  Module  für  das
Modul  ModBase  und  die  Prozedurnamen  entfernt  werden,  wohingegen  beim
anderen Modus diese Daten erhalten bleiben, um dem Modul  GEMError  die
gewohnte Ausführlichkeit bei der Anzeige von Laufzeitfehlern zu bieten.
2.7  Bedienung: Make und ModRef                                        2 - 69
________________________________________________________


2.7    Make  und   ModRef


Prinzip eines Make

Das Make ist ein Hilfsprogramm, das nicht unbedingt zur Programmentwicklung
benötigt wird, das aber bei umfangreicheren Programmprojekten sehr hilfreich
ist.

Arbeiten Sie an einem Programm, das aus  mehreren  Modulen  besteht,  die
häufig geändert werden, müssen Sie ja immer darauf achten, diese Änderungen
vor einem neuen Programmstart zu übersetzen. Bei gleichzeitigen Änderungen
in  mehreren  Modulen  kann  es  vorkommen,  daß  Sie  dann  ein  Modul  zu
übersetzen vergessen. Bei Definitionsänderungen erhalten Sie dann meistens
eine Fehlermeldung vom Loader (welchen die Shell  dann  anzeigt)  oder  vom
Linker, daß  ein  Versionskonflikt  zwischen  den  Modulen  vorliegt.  Im  ungün~
stigeren Fall wird nichts bemerkt und beim Start des Programms machen sich
dann  die  vermeintlichen  Änderungen  nicht  bemerkbar,  was  zu  großer
Verwirrung führen kann.

In diesem Fällen ist es also notwendig, alle betroffenen Module neu zu über~
setzen. Weiß man nicht, welche das sind, ist das dann sehr zeitaufwendig. Ein
Make versucht nun, anhand bestimmter Anhaltspunkte selbst herauszufinden,
welche Module nach erfolgten Änderungen neu zu übersetzen sind. Hierzu gibt
es  verschiedene  Verfahren.  So  könnte  beispielsweise  der  Editor  jedes
geänderte Modul irgendwie markieren, indem es seinen Namen in eine Datei
schreibt. Dann könnte das Make diese Module alle compilieren lassen. Da das
Megamax-System  aber  jeden  beliebigen  Editor  zur  Programmentwicklung
zulassen soll, würde dies Verfahren nicht helfen, weil kein Fremdeditor solch
eine Markierung vornehmen würde.


Arbeitsweise von Make

Die  einzige  Markierung,  die  jeder  Editor  automatisch  nach  einer  Änderung
vornimmt,  liegt  darin,  daß  beim  Abspeichern  jedes  geänderten  Textes  das
Betriebssystem (GEMDOS) die aktuelle Tageszeit und das Datum der Datei mit
im Inhaltsverzeichnis speichert. So kann jedem Text angesehen werden, wann
er zuletzt - wahrscheinlich  nach  einer  Änderung  -  gespeichert  wurde.  Da
ebenso die vom Compiler übersetzten Code-Dateien beim Abspeichern mit der
aktuellen Zeit vermerkt werden, kann das Make durch Vergleich der Zeiten
von Text- und Code-Datei entscheiden, welche Datei jünger ist: Ist ein Text
jünger,  muß  er  compiliert  werden,  wurde  er  daraufhin  übersetzt,  ist  der
resultierende Code jünger, woraufhin das Make beim wiederholten Start nun
alles als aktualisiert erkennt.
2.7  Bedienung: Make und ModRef                                        2 - 70
________________________________________________________


Darin liegt also das prinzipielle Vorgehen beim Megamax-Make. Voraussetzung
ist selbstverständlich, daß Datum und Zeit immer stimmen, damit  ein  nach
einer Übersetzung veränderter Text auch wirklich eine spätere Zeit als die
seines Codes erhält. Besitzen Sie einen Mega-ST, brauchen Sie sich  keine
Sorgen  darum  zu  machen,  weil  diese  Rechner  eine  Batterie-gepufferte
Echtzeituhr enthalten, die auch beim Ausschalten des Computers weiterläuft
(vorausgesetzt,  Sie  haben  auch  eine  geladene  Batterie  eingesetzt).  Den
Besitzern von anderen ST-Computern bieten sich mehrere Lösungen: Auch für
diese Rechner gibt es einsteckbare, nicht-flüchtige Echtzeituhren zu kaufen.
Verfügen Sie nicht über so einen Zusatz, müssen Sie die Zeit nach jedem
Rechnerstart  (auch  beim  Druck  auf  den  RESET-Taster)  neu  stellen.  Dazu
können  Sie  beispielsweise  das  bei  Ihrem  Atari  mitgelieferte  Accessory
CONTROL.ACC  verwenden.  Ebensogut  können  Sie  auch  aus  dem  UTILITY-
Ordner das Programm Timer (Dateiname: TIMER.M) compilieren, linken und als
Accessory mit der Endung ACC auf ihre Boot-Disk kopieren.

Am komfortabelsten für Anwender ohne Echtzeituhr ist  es,  das  Programm
SetTime aus dem UTILITY-Ordner zu verwenden: Es muß übersetzt und gelinkt
und dann in den AUTO-Ordner kopiert werden. Schalten Sie den Rechner neu
ein, erkennt das Programm, daß noch keine gültige Zeit eingestellt ist  und
fordert Sie dazu auf. Wenn Sie dann später den Rechner neu booten, ohne ihn
auszuschalten  (z.B.  durch  Druck  auf  den  RESET-Taster),  überträgt  das
Programm die im Tastatur-Chip des Atari gespeicherte Zeit (die erst beim
Ausschalten des Atari verloren geht) automatisch an das GEMDOS, welches
für die Zeit der Dateien zuständig ist, eine erneute Eingabe bleibt Ihnen damit
erspart.

Das Verfahren des Zeitvergleichs bei den Dateien ist allerdings nicht optimal:
Es kann ja auch vorkommen, daß in einem Modultext nur Änderungen an der
Dokumentation vorgenommen werden, so daß keine Neuübersetzung notwendig
wäre. Das ist eben ein kleiner Seiteneffekt, der wohl auch von Ihnen akzeptiert
werden kann, oder? Nebenbei: Achten Sie auf die Dokumentationen  zu  den
mitgelieferten Editoren. So bietet Ihnen beispielsweise der Gepard-Editor die
Möglichkeit, den Text mit "K" zu speichern. Dann wird die vorige Zeit der
Datei beibehalten, so daß Make nicht darauf anspricht.

Nun ist das Problem der Markierung von Änderungen an den Modulen gelöst.
Aber es gibt noch  ein  weiteres:  Ändern  Sie  ein  Definitionsmodul,  das  von
weiteren  Modulen  importiert  wird,  an  denen  Sie  aber  keine  Änderungen
vornehmen, müssen diese trotzdem übersetzt werden. Damit das Make dies
erkennen  kann,  muß  es  über  die  augenblicklichen  Import-Verhältnisse  der
beteiligten Module informiert sein. Es bietet sich an, ausgehend vom Haupt~
modul des Programms, alle importierten Module zu beschreiben, wiederum mit
deren Importen usw. Diese Beschreibung erfolgt in einer Datei, die dann vom
Make ausgewertet wird:
2.7  Bedienung: Make und ModRef                                        2 - 71
________________________________________________________


Das Make sieht sich zuerst die Definitionstexte in der Reihenfolge an, in der
sie importiert werden: Die Module, die selbst keine mehr importieren zuerst,
die, die von keinem  anderen  importiert  werden  zuletzt.  Ist  dabei  ein  Text
jünger als sein Code, oder existiert der Code gar noch nicht, wird es zur
Übersetzung markiert. Alle Definitionen, die ein markiertes Modul importieren,
werden  ebenfalls  markiert.  Dann  wird  ebenso  bei  den  Implementationen
verfahren: Ist die eigene Definition oder die eines Imports markiert oder ist
der Text jünger als der Code, bzw. fehlt der Code, wird es auch markiert.
Zuletzt werden alle markierten Module in eine Textdatei geschrieben und das
Make sorgt dafür, daß die Module vom Compiler übersetzt werden.


Erstellung einer Make-Datei (ModRef)

In der Make-Datei wird  das  Hauptmodul  mitsamt  aller  importierter  Module
beschrieben. Um solch eine Datei zu erzeugen, kann das Programm ModRef
verwendet werden. Am besten melden Sie ModRef als Tool an (siehe Kap. 2.2,
Batch-Dateien).

Wird ModRef ausgeführt, zeigt es den GEM-Datei-Selektor, mit dem dann ein
Hauptmodul (üblicherweise Dateien mit der Endung "M") ausgewählt  werden
kann.  Dann  liest  das  Programm  den  Quelltext  ein  und  registiert  all  seine
Importe. Danach werden all die importierten Module gesucht, und zwar sowohl
die Code-Dateien von Definition und Implementation als auch die zugehörigen
Quelltexte.  Dabei  werden  Module  ignoriert,  deren  Definitions-Codes  in  der
unter den Compiler-Parametern eingetragenen Bibliotheks-Datei enthalten sind.
Das hat den Effekt, daß solche Module dann nicht mehr vom Make geprüft zu
werden brauchen, was bei den in der Bibliothek enthaltenen Megamax-Modulen
auch nicht mehr nötig ist, da ihre  Codes  sowohl  vorhanden  sind  als  auch
normalerweise nicht verändert werden.

Werden  Texte  von  Modulen  nicht  gefunden,  werden  sie  auch  nicht  in  der
Make-Datei  berücksichtigt,  zur  Sicherheit  erfolgt  aber  ein  Hinweis  vom
ModRef, daß es bestimmte Dateien nicht finden konnte. Wenn Sie vor dem
Start  von  ModRef  nur  bestimmte  Verzeichnisse  als  Suchpfade  für  die
Quelltexte eintragen (z.B. mit Hilfe von PathEdit), können Sie bequem Modul~
sammlungen für verschiedene Projekte auseinander halten.

Sind  alle  Importe  festgestellt,  erscheint  der  Datei-Selektor  von  Neuem.
Normalerweise ist nun Abbruch zu wählen, woraufhin eine Make-Datei erzeugt
wird, die den Namen des Hauptmoduls trägt, jedoch mit der Endung M2M. Die
Datei  wird  im  selben  Verzeichnis  abgelegt  in  der  auch  der  Quelltext  des
Hauptmoduls  steht.  Statt  des  Abbruchs  kann  auch  ein  weiteres  Modul
angewählt werden. Dann wird dieses Modul samt seiner Importe ebenfalls in
die Make-Datei aufgenommen. Damit wird erreicht, daß bei einem Make auch
zusätzliche zum Projekt gehörende Module gemaked werden können.
2.7  Bedienung: Make und ModRef                                        2 - 72
________________________________________________________


Wollen  Sie  gar  alle  Module  aus  einem  Verzeichnis  in  die  Make-Datei
aufnehmen,  können  Sie  den  Modulnamen  mit  Wildcards  eingeben,  also
beispielsweise *.M für alle Hauptmodule des Verzeichnisses.

Muß häufig die selbe Make-Datei neu erzeugt werden (s.u.), kann dies über
einen Batch vereinfacht werden: Schreiben Sie einen Batch, der die folgende
Zeile enthält:
  ModRef  <Quelltextnamen>
Melden Sie diese Textdatei (mit Endung M2B!) am besten als Tool an. Wird
dieser Batch ausgeführt, wird nicht mehr mit dem Datei-Selektor nach dem
Quelltextnamen gefragt, sondern der angegebene verwendet. Es können auch
mehrere  Textnamen  hintereinander  aufgeführt  werden,  um  dasselbe  zu
erreichen, wie durch die wiederholte Auswahl mit dem Datei-Selektor.

Es ist darauf zu achten, daß bei jeder Änderung der Import-Strukturen der
beteiligten  Module  die  Make-Datei  neu  erzeugt  wird!  Wird  dies  vergessen,
arbeitet das Make zwar meist einwandfrei, trotzdem zeigen sich beim Start
des Programms oft Fehler, wie beispielsweise Versionskonflikte.


Anwendung von Make

Das  Make-Programm  heißt  MM2Make  und  wird  in  den  Shell-Parametern
eingetragen. Der Aufruf erfolgt, indem eine Make-Datei  (Endung  M2M)  zur
Ausführung gebracht wird, indem sie also beispielsweise aus einem Fenster auf
das Ausführen-Symbol gezogen wird. Selbstverständlich können Make-Dateien
auch als Tool angemeldet sein.

Einen Sonderstatus genießt die Make-Datei, die als Default-Make eingetragen
ist (unter Info/Umgebung). Sie kann jederzeit durch die Taste M in der Shell
oder durch eine Sonderfunktion beim Verlassen der Editoren (siehe Kapitel 2.3)
aktiviert werden.

Bei  der  Aktivierung  des  Make  wird  zuerst  die  betroffene  Make-Datei
eingelesen,  dann  werden,  wie  oben  beschrieben,  die  Datumseinträge  der
Dateien geprüft. Am Ende wird eine Datei, die alle zu übersetzenden Texte
aufführt, unter dem Namen MAKE.M2C im temporären Pfad (einzustellen in
den Shell-Parametern) abspeichert. Sind keine Dateien zu übersetzen, liefert
MM2Make den ExitCode Eins, sonst Null. Daran erkennt die Shell dann, ob sie
daraufhin  den  Compiler  aufrufen  soll.  Der  übersetzt  dann  die  geforderten
Module alle auf einmal.

Zeigt das Make also den Fehler Ausgabedatei konnte nicht angelegt werden an,
liegt es meistens daran, daß der temporäre Pfad nicht auf ein vorhandenes,
beschreibbares Verzeichnis zeigt.
2.7  Bedienung: Make und ModRef                                        2 - 73
________________________________________________________


Stößt  der  Compiler  beim  Übersetzen  auf  einen  Fehler,  wird  der  Editor
gestartet, um ihn wie gewohnt anzuzeigen. Ist der Fehler korrigiert, kann das
Make fortgesetzt werden, indem der Editor mit dem Kommando zum Make
verlassen wird. In diesem Fall wird nicht das Default-Make sondern die aktive
Make-Datei wieder verwendet, mit der ein erneuter Make-Aufruf stattfindet.

Wird der Editor nach einem Fehler nicht mit dem Make-Kommando verlassen,
erinnert die Shell daran, daß der Make-Vorgang noch nicht abgeschlossen ist,
und bietet Ihnen an, diesen fortzuführen oder abzubrechen.

Sind syntaktische Fehler in der Make-Datei vorhanden, oder können benötigte
Dateien nicht gefunden werden, wird das Make abgebrochen und entweder die
Fehler auf dem Bildschirm angezeigt oder der Editor geladen, um dort den
Fehler in der Make-Datei anzuzeigen.


Alle Module unbedingt übersetzen (Build )

Wollen Sie alle Module einer Make-Datei unabhängig von ihrem Datum über~
setzen, können Sie dies dem Make-Programm durch Übergabe der Option "-B"
mitteilen. Entweder starten Sie das Make-Programm manuell (im Batch oder
durch Doppelklick) und übergeben in der Argumentzeile den Make-Dateinamen
zusammen mit -B oder Sie tragen -B hinter dem Namen der Make-Datei in
den Umgebungsinformationen ein. Das hat sogar den Vorteil, daß  das  "-B"
nach dem Make wieder daraus entfernt wird - denn einmal reicht's ja wohl.


Fehlermeldungen des Make

Zu wenig Speicher.
  Abhilfe: Residente Module/Programme entfernen.
Make-Datei ist leer.
  Die eingelesene Make-Datei enthält keine Daten
... hat ungültiges Datum.
  Die Zeit der angezeigten Datei liegt hinter der aktuellen Zeit.
Dateifehler: ...
  Fehler beim Einlesen oder Anlegen der Datei.
Modul ist doppelt deklariert.
  Jedes Modul darf nur einmal in der Make-Datei deklatiert werden.
... wurde nicht oder unvollständig deklariert.
  Das Modul ist bei IMPORT angebeben aber nicht deklariert.
Datei(en) nicht gefunden.
  Die Datei(en) sind nicht auf den entspr. Suchpfaden zu finden.
Ausgabedatei konnte nicht angelegt werden. (Stimmt "Temp.Pfad"?)
  Wahrscheinlich ist der Temp. Pfad in den Shell-Parametern ungültig.
Syntaxfehler.
  Wahrscheinlich wurde zuvor ein Semikolon bei einer Modulliste vergessen.
2.7  Bedienung: Make und ModRef                                        2 - 74
________________________________________________________


Syntax der Make-Dateien

moduldefinition =
  <modulname> ( -IGNORE | codedefinition )

codedefinition =
  ( -MOD | -IMP | -DEF ) <dateiname>
    -MAIN
  ( -NOSRC | sourcedefinition )

sourcedefinition =
  -SOURCE <dateiname>
    -INC <dateiliste)
    -USES <dateiliste)
    -IMPORT <modulliste)

dateiliste =
    dateiname   ";"

modulliste =
    modulname   ";"

Jedes in der Modulliste (nach -IMPORT) vorkommende  Modul  muß  definiert
sein! Wird es mit -IGNORE definiert, wird es vom Make ignoriert. Mit -INC
können Dateien bestimmt werden, die mittels der Include-Direktive mit in den
Modulsource eingebettet sind. Mit -USES können weitere abhängige Dateien,
z.B. Resource-Dateien, aufgeführt werden. -NOSRC besagt, daß der Quelltext
zu  diesem  Code  vom  Make  nicht  berücksichtigt  werden  soll.  Die  Kennung
-MAIN sollte nur bei einem Modul auftauchen.  Damit  wird  das  Hauptmodul
markiert, das nach einem erfolgreichen Make-Prozeß ggf. gestartet werden
kann.